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INTRODUCTION 


Telecommunications devices are being used widely to give more peopte 
direct access to computer services and to make computer systems sore 
responsive to the needs of the people who use theme Howevers along 
with the benefits of telecommunitcations come increased programming costs 
required to handtie the special problems of the on-line environment. 
Burroughs B 1800/8 1700 Generalized Message Controt System (GEMCDS) is 
designed to help reduce these costs by providing services which can 
enhance most oneline application programs. 


This manual explains the system with highwLevel descriptions of compo- 
nents and capabilities and detaited specifications of how to use 
GEMCOS. 


GEMCOS is available in three versions in order to accommodate any Level 
of operating complexity. These verstons are the Basic Versions the 
Advanced Version and the Total Versione The major capabilities of each 
of these versions are: 


ae Basic Version GEMCOS: 


1) Transaction Controt Language (CTCL). 
2) Access control. 

3) Message routinge 

4) Message auditing. 

5) Network control. 

6) Message recovery. 

7) =Nonparticipatijng MCS. 


be. Advanced Verston GEMNCOS: 


1) All Basic Version capabilities. 
2) Message formatting. 


ce Total Version GEMCO0S: 


1) ALL Advanced Version capabilities. 
2) Data base and synchronized recovery. 


The style identification numbers for the GEMCOS product are 81800/8B1700 
GPB» GPA» AND GPT when purchased with the UPL Compilers or B1800/81700 
MCB» MCA» AND MCT when purchased without ite 


The material tn this manual is supplemented by those portions of the 
following documents which pertain to Message Control System or Network 
Controller interfaces: 


ae Burroughs 8 1700 Systems Network Definition Language 
Reference Manuals» form 1073715. 


be Burroughs 8 1700 Systems User Programming Language Reference 
Manuals form 1067170. 


Xil 


he 


Burroughs B 1800/B 1700 Systems System Software Operational 
Guides forn 1068731. 


Burroughs 8B 1700 Systems COBOL Reference Manuals forse 1057197. 


Burroughs B 1700 Systems Report Program Generator Reference 
Manual» forrg 1057189. 


Burroughs B 1700 Systems Data Communications Information 
Manuals fora 1089992. 


Burroughs B 1800/8 1700 Generalized Message Control 
System (CGEMCOS) Formatting Guides» form 1106531. 


Burroughs B 1800/B 1700 Generalized Message Control 
System (GEMCOS) Capabalittes Manuals» fora 1106572. 


GENERAL} 


SECTION 1 


SYSTEM OVERVIEW 


GEMCOS is a systen of programs and files whose purpose is to create and 
support a Message Controt System (MCS). 


NCS_PROGRAMe- 

An MCS manages the flow of messages Detween the Network Controiler (NC) 
and the applicatton system (see figure iri). The MCS program created 
by GEMCOS is designed to: 


ae 


Direct messages agong telecommunications stations and 
application programs according to user-defined routes. 


Keep unauthorized persons from using telecosmunicattons 
Stations to gain access to the application. 


Require authorized personnel to perform certain functions. 
Prevent data communications errors from affecting application 
programs or unduly tmpeding operations in the rest of the 


data communications networke 


Gather statistics about data communications errors to aid in 
diagnosing hardware problems. 


Adapt dynamically to changing conditions in the network. 


Log messages and return them to application programs on 
demand « 


Inform the network controtier of the network status before 
a system failure. 


Provide an orderty network shutdowns accouting for ali 
messages 3n processe 


Segment messages (Cif necessary) to fit the buffer of 
destination stations. 


Provide remote stations the ability to execute programs. 
Allow remote stations to switch between MCS programs. 
Furnish useful information to application prograns. 


Format messages and provide a screen request function Cadvanced 
version only). 


Altow of f-tine testing of the MCS. 


i-i 


pe Provide debugging aids. 


qe Provide audit and recovery capability at the program or 
data base ievel. 


The MCS is generative» so not alt of these capabilities need to be pre- 
sent in any specific version of the MCS.j The generative feature aiso 
alious for inclusion of user~written code in the MCS to supplement or 
supplant its standard functions. 


APPLICATION 
PROGRAMS 


NE TWO RK 


NETWORK | 
MANAGER'S 
STATION 


GEMCOS NETWORK 
CONTROLLER 
MCS 


Figure iri. System Structure 


TRANSACTION CONTROL LANGUAGE COMPILER. 

The Transaction Control Language (TCL) is the means by which the user 
describes the data communications environment and requirements. The 
user specifies such information as message routing criterta»s access 
control requirements» and MCS options using TCL. 


TCL is a free-form structured language utilizing key words to describe 
the envtronment and requirements of the data communications user. Con 
piling TCL generates a set of tables describing the user data comauni- 
cations system ands if requested» MCS codee The compitier CMCSTCL) 
produces an optional hard-copy listing of the user’s data comaunication 
system. It also provides extensive syntax checking to ensure that the 
MCS ts properly defined. 


The TCL for the B 1800/8 1700 GEMCOS is similar to the TCL of CMS GEMCDS 
and B 7000/B 6000 GENCOS. 


MCSTICe. 
The Table Information Controt file» MCSTIC» is used by the MCS to store 


some of tts tmportant variables and parameters. By storing therm in a 
disk file» they are preserved froa one execution of the MCS to the next 
and are protected in case the MCS ts unconventionally terminated. 
Moreovers should system relationships changes the TCL compiler rewrites 
the MCSTIC file. 


MCSEORMATS< 


In the advanced and total versions of GEMCOS» ali functions and formats 
created by the TCL compiter are stored ina separate disk fila called 
MCSFORMATS. 


AUX ILTARY_ PROGRAMS © 


In addition to the previously menttoned programs» the system contains 
three utility prograas: MCSSIMs» MCSFIX» and MCSRECALL.- 


MCSSIM. 

The program MCSSIM is used to test the MCS and uservwwritten code off- 
tine. Simulated input messages are presented to MCSSIM using a card 
reader. MCSSIM forwards thea to the MCS as tf they had some from the 
Network Controller. Outputs are printed on a system printer. 


MCSFIX. 
This program patches and/or tists sourcecode fiies which are on disk 
in the User Programming Language (UPL) format. 


MCSRECALL. 

This program allows the user at a station to recalt audited input or 
output messages. These messages can be sent either to the station or 
to the system printer. 


SECTION 2 


CAPABILITIES 


APPLICATION=PROGRAM_ INTERFACE. 

The MCS communicates with Application Programs through the resote file 
interface» but it provides some optional extensions to the standard 
interface. Application Programs may be written in any ftanguage that 
supports remote or data communications files. 


A standard remote file provides a tink between an application prograr 
and one or more data communications stationss which were dectared 

as betonging to that file in the FAMILY statement of NDL.~ Messages are 
exchanged in the record area of the fiie.w In COBOL» an actual key can 
be used to exchange information about the messages namely» message 
type» message length» and source or destination station. Stations are 
identified by a number which is relative to the order in which the 
stattons were assigned to the fite tn the FAMILY statement. 


GEMCOS offers a Common-area header option which overrides portions of 
the standard interface. Commmon area is a header which appears in the 
record area of a file in front of the message. Common area contains 
the following fields: 


ae Logical Station Number (LSN) - identifies the source or desti- 
nation station. The LSN is a number which is relative to the 
order in which stations are defined in the STATION section of 
NDL. This identifier is not necessarily the same as that used 
in the actual COBOL key. 


NOTE 
The LSN of a given station changes if 
Stations are presented ina different 
order when the NDL is recompiled. 


b. Message type ~ distinguishes between normal messages and mes- 
sages used for special purposes» such as recoverys FILE 
OPEN notifications FILE ATTACH notifications and FILE DETACH 
notification. 


ce Sequence nuaber - assigned by the MCS» primarily to aid in 
recovery. 


de. NDL time - contains the time at which the Network Controller 
sends the message to the NCS. 


ee. Message text stze = indicates the length Cin bytes) of an 
incoming message» not including the Common~area header. 


“ - Terminal type = identifies the kind of terminal or d2vice from \ 
. which the message originated. : 


ge Message identifier - allows Application Programs to specify 


which formatr if any» is to be applied during output Cadvanced 
version only). 
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he Trancode (transaction code) index 1 ™ assists the application 
program to determine which transaction was received. 


ie Vrancode index 2 ~ further assists the application program to 
determine which transaction was received. 


j- Format error indicator - notifies the application prograa that 
at feast one field of an input message is in error Cadvanced 
version ontly). 


ke Input address - address in the audit file of this message. 


lt. Retry count - the number of times this message was submitted 
to an Application Progran. 


me. Recovery status - indicates tf this message is a normal ses- 
Sage or a recovered messagee 


ne Output address ~ address in the audit file of the correspond- 
ing output gessagee 


oe User area ~ aktows the user to reserve space in the Common-area 
header for uservwdefined fields. 


When the Common-area header is used» the MCS attaches tha Common-area 
header to each message sent to an Application Program and removes it 
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from each message received from a1 application program» so that the 
Comson-area header does not accompany the message on the Network 
Controller side of the MCS. 


The actual key in COBOL should only be used for specifying the text 
Size of an outgoing sessage-e 


When an Application Program receives a message from the MCS» the LSN 
field in the Commoncarea header is set to the originating station. As 
long as the LSN remains unmodified at the time the application sends a 
response back to the MCS» then the MCS routes it back to the same 
Station. But» if the application requires that the response be sent to 
some other stations then that is accomplished by merely changing the 
LSN field to the correct value for the other station. 


TRANSACTION“BASED ROUTING. 

By using the FAMILY statement of NDL» the network designer can associ- 
ate a list of stations with a reaote file name. When an application 
program successfully opens a resote file» the stations tn the fapily 
associated with that file becomes tin a senses “attached” to that pro- 
grame From that time ons the Network Controtler routes messages from 
that family of stations only to the program that opened the file. 


However» GEMCOS offers an optional alternative to station attachment: 
Transaction~Based Routing CTBR)- Messages may contain transaction 
codes anywhere in the text. TBR allows a group of transaction codes 

to be associated with each application programs so that a message 
containing a specific transactton code is always routed to th2 sane 
program» regardless of the meSsage sourcee A station can then send a 
message to any program (subject to. security restrictions) by including 
in the message one of the transaction codes associated with that 
program. If a message does not have a transaction code or the transacm- 
tion code is invalid» the message ts sent to the program which is 
attached to the originating station. If no program is attached to that 
stations the message is rejected. 


ACCESS CONTROL: 

In GEMCOS there are two types of access control: access security and 
process security. Access security is designed to prevent unauthorized 
persons from using the system. Process security Limits the functions 
that authorized persons are allowed to perform. <A specific MCS nay be 
generated to contain logic for access security alone or for both access 
security and process security. 


ACCESS SECURITY. 

Access security ts iaplemented through sign-on and sign-off massages. 
Some stations may atready be physicatly secures therefore», signing on 
is not necessarily required for all stations. Each installation may 
specify which stations do not require signing on. 


The sign-on message requires that each potential station user supply a 
user~identification code (access key). A List of active access keys is 
defined tn TCL and is stored in the MCSTIC file. Moreover» for each 

Station that must be signed ons TCL can be used to specify which access 
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keys are to be recognizede The TCL compiter can be used to update this 
information. At any specific time a user station may be either enabled 
or disabled. If disabled» then that user is not aitowed to sign on 
until enabled again. 


A user is altowed to sign on only if alt of the fotlowing conditions 
hoids 


ae The station requires signing one 
be The station is not already signed on. 
ce The user enters a valid access code. 


de The access code entered is to be recognized at the station 
being signed on. 


A user is allowed to enter a data message only if one of the 
following conditions holds: 


ae The terminal does not require signing one 
be. The user %s signed one 


The same access key can be used t)2 sign on at several stations 
stimudtaneously. 


PROCESS SECURITY. 
GEMCOS offers two types of process security: 


ae Transaction security = for limiting which transaction codes 
can be entered by a signed-on user. 


be. Program security ~- for Limiting which programs san be used by 
a signed-on usere Program security is used when messages do 
not have transaction codese 


As access codes are defined in TCL» they are associated #aith a tist of 
valid transaction codes and/or prograa identifiers. Once signed one a 
particular access key is restricted to those transactions and/or pro- 
grams with which it was associated. Hences each access z:ode can be 
Limited to any station» programa» or trancode combination. 


NETWORK _ADNINISTRATION. 

Although the MCS and Network Controller automatically controt many 
aspects of the network» some conditions still require husan interven- 
tion. For this reasons GEMCOS supports the CONTROLSTATION coacept. 
The supervisory console can always be used as a Control statton. In 
additions one remote station can be designated as the Control station. 


A control station administers the network through Network Control 
Commands (NCCs). GEMCOS recognizes Network Controt Command syntax for 
the following functions: 


ae Access control. 
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1) Enable and disable userse 
2) Stgn on and off. 


be MCS control. 
Ce Message controti. 
1) Reroute messages. 
2) Retrieve queued messages. 
3) Send messages to other stationse 


de Program control. 


1) Execute and terminate Application Programs. 
2) Report program statuse 


ee Station statuse Report and change status of stations. 


The MCS need not contain logic to execute atl these commands since there 
are TCL parameters to specify which commands are needed. 


Use of Network Control commands is restricted by the GEMCOS security 
subsystem. Some commands can be entered by any one at any station 
Cie@e» the sign-on and sign-off commands)» but many commands can only 
be entered at the Console station. All Network Controt Commands can 
always be entered at the console keyboard without restriction. 


ERROR HANDLING. 

The GEMCOS error handling subsystem provides the necessary logic to 
handie error conditions which are not directly related to the applica- 
tions task at hand (thereby relieving the application programner of 

that burden). With GEMCOS» enough automatic action is taken to keep the 
data communications system runnings and the error condition is 
communicated to the person who has the power to correct the problen. 


GEMCOS distinguishes three error categories: 


ae Errors aade by a station operator. 
be. Persistent data communications errors. 
Ce System errorse 


When a GEMCOS MCS detects errors made by a station operators error 
messages are sent back to that operator. For other kinds of errors,s 
mesSages are sent to the Control station or to the console printer» 

aif the Control station is not available. Network Control Comaands may 
then be used to help diagnose the problem or circumvent it. 


The Network Controller handtes transtent data communtcati ons 2rrors»s 
but persistent errors are reported to the MCS. The MCS not onty 
reports such errors to the Controt station but also keeps error statis-~- 
ticse Statistics are accumulated by station. They can be retrieved by 
using Network Control commands. 


System errors resuit either from tnput/output errors on peripheral 
devices used by the MCS or from software problems in the MCS» the 
Network Controllers or the applicattons programs. When a system error 
as detected» the MCS reports the error to the Controt station. For 
serious errors» the MCS also produces a dump of its tables for debug- 
ging purposes. The MCS ts designed» however» to continue running 
unless the Control station or system operator discontinues it. 


NETWORK RESTORATION. 

The purpose of network restoration ts to bring the Network Controller 
up~to~date with MCS data on network statuse Network status consists of 
information such as the current physical address of a stations or whe- 
ther a station ts “*altive™ or “dead.* The MCS stores current network 
status information on disk file MCSTIC Cat a Location that is protected 
from abnormal prograsa termination). Network restoration is done 
automatically. 


Each time the MCS is executed» it uses the status data from the MCSTIC 


file to generate commands for the Network Controtter. The Network 
Controlter uses these commands to update its tables in smain memory. 
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MESSAGE RECOVERY. 

GEMCOS provides message recovery at etther the program or data base 
devel via an audit trail to help application programs re:over froan 
failure. Through TCL parameters» an MCS can be created with just the 
audit feature or with both audit and recovery. 


AUDIT. 

When the audit option is used» the MCS keeps an audit trail of all mes- 
Sages sent to an Applicatton Programs. OQutput messages may be audited 
for nonsynchronized recovery» but must be audited for synchronized 
recovery. Messages are identified by a sequence number which the MCS 
assignse The Commonw-area header is used to communicate the s2@quence 
number to Application Programs. For synchronized recovery (total 
version only)» a data base sequence number is also assigned upon re- 
ceipt of the output sessage. 


The audit trail is written on a disk file. When the audit file becomes 
filled» it is closed and a new one 18 opened. The fite is then avail- 
able for copying to another device. Each new audit file has a file 
identifier which is different from the Last. 


RECOVERY. 

GEMCOS provides numerous recovery capabilities within the TCL. The 
user has the flexibility to analyze application-oriented needs and 
select the recovery options required on a prograag~by-program basis. 


Recovery capabitities range from a rather simple queue restoration 
technique to an automatic data base roilback and synchronization scheme. 
Once agains the emphasis 1s on providing users with the flexibility of 
easily adapting to meet a broad range of onwline data processing re- 
quirements. 


CONTROLLED. SHUTDOWN. 

When a data communications systea terainates operations» messages may 
be tost in the process of terminating unless special care is taken. 
In GEMCOS» system shutdown consists of the fotlowing steps: 


ae A message is sent to alt stations» tnforming them that 
shutdown has begun. 


be Further input ts disabled. 
ce The MCS causes an End-Of-File condition on alt remote files. 


de. Any messages that may remain in the queues of the Network 
Controtler are recaited and printed on a tine printer. 


ee. The MCS terminates. 


Any messages that coutd not be delavered to their destinations are 
accounted for on the printer Listing. 


MERGEASLE EXTERNAL. SOURCE STATEMENTS» 


Mergeabie External Source Statements (MESS) are used for specialized 
requireaents which demand deviation from the standard GEMCOS Logic. 
User-written MESS routines can be merged into key tiocations tn the 
MCS lLogice Each routine must be a procedure in User Programsping 
Language (CUPL). A&l MESS routines are optional. Most MESS routines 
can either replace or supplement standard GEMNCOS logic. 


The MESS procedures can be inserted in the following code tocatiaons 
Cthe intended function of each procedure is explaineds but there is 
practically no Lamit to the functions that can be coded): 


ae Receiving message from station - for formattings paging» o 
routinge 


b. Receiving message from program - for formattings paging» or 
routing. 


Ce Processing Network Control commands - for extending or 
replacing the capabilities for network control. 


de Auditing - for replacing or supplementing the standard audit 
feature. 


ee Error handling - for extending the standard error~handling 
Logic. 


f.- Opening - for processing required at system startup. 


ge Closing - for processing required at system shutdowns such as 
closing files used by other MESS procedures. 


he Recatling messages - for disoosing of unsent messages when the 
System is shut down. 


1- Initiating recovery ~- for processing the request of an 
Application Program for recovery. 


j- Recovery - for replacing the standard recovery logic. 


ke Remote File Open - for processing that is required when an 
Apolication Program opens a remote file. 


tl. Remote File Close - for processing that is required when an 
Application Program cioses a remote file. 


The source code for MESS procedures is submitted as part of the user's 
TCL source file. The TCL compiler merges these procedures into the 
correct places in the MCS Logic. 


DEBUGGING AIDS. 
GEMCOS offers two kinds of debugging aids: a data dump and a logic 


flow monitor. The existence of these features is controlled by TCL 
paraseters. 


DATA DUMP. 

The data dump provides a snapshot of the state of the MCS and its 
environment. It displays the contents of the tables» certain signifi- 
cant data items» and the message work areae It can be used for debug- 
ging purposes and for reporting statistical information maintained in 
the tables. A data dump can be created on demands via a Network 
Control commands or automatically» when the WCS detects a serious error. 


MONITOR TRACE. 

The monitor is a procedure within the MCS which produces a listing that 
can be used to trace togic flow. Catils on the monitor are made at the 
entrance to nearly every procedure and at other key points in the MCS. 
Since MESS procedures can also calli on the monitors the monitor is a 
vaiuable tooi for debugging interfaces between MESS code and the 
standard MCS. 


The monitor tisting displays: 
ae An identification of the procedure now executing. 


be An identificatiqn of the procedure which called the current 
procedure. 


ce Any information that is pertinent to the current procedure. 


de The sequence number in the MCS source code file at the point 
where the monitor was cailed. 


Since the monttor is a generative options the MCS used for nor- 

mal operation does not have to carry the overhead of monitor logic. 
Users can generate a second MCS which is exactly like the production 
MCS except that the MONITOR generation parameter is sete This second 
MCS would be used only if probleas arise which cannot otherwise be 
diagnosed. 


When an MCS is generated with the MONITOR parameter set» the aon- 
itor listing can be turned on and off either dynamically» by a Network 
Control command» or between executions of the MCS by the TCL compiter. 
Furthermore» the monitor can be selected for individual procedures» or 
for onty those procedures suspected of being related to a problen. 


2CREEN WRAPAROUND» 

To provide Application Programs with enhanced terminal independence» 
GEMCOS can automaticaliy segment messages to fit the buffer of the 
destination station. Instead of transmitting a message that cannot 
be accepted by a station because of its Lengths the MCS san break the 
the message into two or more transmissions. 


The message is segmented on word boundaries whenever possibte. The 
segment will be as Long as is possible without splitting a word or 
exceeding the buffer at the station. If the message contains a string 
of nonblank elements that is greater than the station buffer size» it 
is necessary to break the string into one or more transmissionse Using 
screen wraparound is not recommended with messages that contain for- 
mats. <A formatted message could be segmented in the middle of a foras 
field. <A warning message is sent to the Control station when screen 
wraparound sends a formatted message to a station. 


Code for screen wraparound 18 generated when the station scre@ansize is 
declared targer than the Globadi MAXTEXTSIZE. 


Q2UPERVISORY NCS 

GEMCOS provides a supervisory MCS functton allowing stations to be 
Switched between MCS prograsse The user say» for examples use CANDE 

and ODESYs» which are both MCS programs and switch between therm as the 
need arisese Without a supervisory MCS» both CANDE and JDESY would 

have to be shut down and restarted to switch stations» resulting in con- 
siderable inconvenience to the rest of the station operators. Howevers 
with GEMCOS Network Control commands» station operators can switch from 
one subordinate MCS to another without interrupting the other operators. 


REMOTE PROGRAM EXECUTION. 

Among the onwrline applications of a given installations there may be 
programs which would be most conventently used tf they could be executed 
remotely. GEMCOS provides this capability. Alf on-line programs need 
not be executed remotely» however. There are situations where it is 
desirable to have centralized controt over program execution. GEMCDOS 
also provides the ability to exercise centralized control via the 
supervisory console or a remote control statione 


FORMATTING. 

One of the sajor problems of on-line programming is the human interface. 
Since the system can interact with many individuats through stations» 
some of whom may only spend a smatl percentage of time working with a 
terminals it is important that the input and output be as “humanly 
readable” as possible. Proper formatting of information exchanged 
between the terminal and the system provides this readability. 


When approaching the probtem of forsmattings the strategy employed must 
be chosen carefully. Application Programs can be written to expect and 
create readable messagese Howevers they then become much mor2 coaplexe 
especially if several terminal devices are involved. Moreovers if 
existing terminal devices are replaced with others» the application 
programs must be converted. Application Prograas are much easter to 
write and maintain if they read and write records instead of sessages 
that can be clearly understood by people. 


The GEMCOS formatting function of the advance version was designed with 
these aspects in mind. It can be used to support foras requests» 
enhance the readability of message text and ensure Appiitz ation Prograa 
device independence. 


SECTION 3 


TRANSACTION CONTROL LANGUAGE 


GENERAL DISCUSSION OF TRANSACTION. CONTROL LANGUAGE CTCL). 

The B 1800/8 1700 Transaction Controi Language is ciassified as a 
descriptive Language. It is a high-level Language providing a siaple 
means of selecting required MCS functions and describing on-line systen 
relationships. The resuit of a TCL compitation 1s an MCS program con- 
posed of GEMCOS intrinsics and a data file consisting of on-line 
relationships. CAn MCS is a program which works closely with a Network 
Controller to provide functions such as remote fite controls 2rror 
handling» access control» audits routings formattings ets.» for on-line 
application programs.) The size limitations of the TCL :ompiter are 
given in appendix G. 


If the requirements of the MCS or the relationships with which tt 
operates changes a naw system may be easily obtained by recompiling. 


The TCL compiler is found on a GEMCOS retease tape in a file Labeled 
MCSTCL. When MCSTCL is executed» tt awaits a TCL source deck Labeled 
MCSIN.j The cards which compose a TCL source deck are similar to those 
of a UPL source deck: 


ae Columns 73 through 80 are reserved for sequence nuab2rs. 
Db. Comments may occur on any card fodlowing a "Z". 
ce Statements may begin in any column. 


The TCL compiter does not permit a continuation from one card to the 
next. If a string ts begun on a cards tt must end on that card. 


SYNTAX CONVENTIONS. 
The following is a discussion of the Backus-Naur fora us23d to describe 
the syntax of the TCL. 


METALINGUISTIC SYMBOLS. 

A metalanguage is a Language used to describe other langsages.e~ A meta~ 
Linguistic symbol is a symbol used in a metalanguage to define the syn- 
tax of a Language. The following metalinguistic symbols are used in 
this document: 


ae Left and right broken brackets (< >) are used to contain one 
or more digits and/or tetters representing a metalinguistic 
variable whose definition is given oy a metalinguistic formula 


be The symbol (€2:2=) means “is defined as*. The metatlinguistic 


variable to the left of this symbol is defined by the seta~ 
Linguistic formula on tts right. 
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ce. The stash (/) means "or". It separates aiternate definitions 
of a metalinguistic variable. The conventional syambot of a 
vertical bar ts not used in this document to represent the word 
“or « 


de Brackets (CC J) are used to enclose metalinguistic variables 
which are defined by the meaning of the English language expres- 
ston contained within the bracketse This formulation its used 
only when it is impossible or impractical to use a gatalinguistic 
forsula.e 


METALINGUISTIC FORMULAE. 

Metalinguistic symbols are used in forming a metalinguistic foraulae A 
metalinguistic formula is a ruie which produces an allowable sequence 
of characters and/or symbols. These formulas are used to define the 
syntax of the TCL. The syntax» combined with the semantics contained 
in this manuals defines the TCL. 


Any mark or syabol ina metalinguistic formula which is not one of the 
metalinguistic symbols is equivatent to itself. The juxtaposition of 
the metalingutstic variables and/or symbols in a metalinguistic formuta 
denotes the juxtaposition of those elements in the construct indicated. 


An example of a metalinguistic formula is: 


<identifier> ::= <letter / <identifier> <letter> / 
<identifier> <digit> 


This metalinguistic formula its read: 


An identifier tis defined as a letters» or an identifier fotlowed 
by a letter» or an identifier followed by a digit. 


The metalinguistic formula above defines a recursive relationship by 
which a construct called an identifier may be formed. That is» evaiua- 
tion of the formula shows that an identifier begins with a tetter. The 
letter may stand alone» or may be followed by a sequence of letters and 
digits. 


NOTE 
Beginning with the heading “Character 
Set»" atl information contained in this 
section is presented in the following 
order: 1) Set» Descriptions Sections 
Statements Command or Dectarations 2) 
Syntaxs 3) Semantics» &) Pragmatics»s if 
applicables and 5) Exampte(s)» if any. 


CHARACTER SET- 


The character set for which the Language is defined is drawn froa the 
Extended Binary-Coded Decimal Interchange Code CEBCDIC) character set. 
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Cone horizontal position) 


Syntax: 

<letter> Ss= A/BZ/ 
JI/K« 7 
S/T 

<digit> s3s=- 0/17 
9 f 

<special character> ss= « J wp 
$ f/f 
<single 

<stash> ss= / 

<single space> $3= 

<space> s3= <single 
<sangle 

<character> s3= <¢string 
<string 

<string character> ee 


<string bracket character> s3= 
<empty> ssc 


Semantics: 


space> / <space> 
space> 


character> / 
bracket character> 


<Letter> / <digit> / 
<special character> 


{the nutl string of symbols} 


The character set for the handter define ts a 52-character subset 
of the EBCDIC character seat containing tetterss digits» special 
characters» the string bracket character» and the space. 
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BASIC SYMBOLS < 


Syntax: 
<basic symbol> ss= <letter> / <digit> / <deli miter> 
<delimiter> 33= <assignment operator> / <separator> 


<assignament operator> :s= = 
<separator> 22= » J « / 3 ¢ <space> / 3 
Semantics: 


Only uppervrcase letters are persmitted. Deltaiters separate vartous 
entities that make up a systea definition. 


Basic Components 


BASIC COMPONENTS» 
Syntaxs 


<basic component> *2= <identifier> / <generalized tdentifier> / 
<integer> / <string> / <logical value> 


Semantics: 


Basic components are the priae structures of the 
language. 


Basic Components 


cont 


IDENTIFIERS. 
Syntax: 


<identifier> s:s:= <letter> / <identifier> <letter> / 
<identifier> <digit> 


Semantics: 


The maximum tength of an identifier is 30 characters. 
not appear as part of an identifier. 


Spaces gay 


Basi: Components 


cont 


GENERALIZED IDENTIFIERS. 
Syntax: 


<generalized identifier> 2:3= <identifier> / 
<generalized identifier> <stash> 
<identifier> 


Semantics: 


A <generalized identifier> may contain a maximum of 3 
identifiers separated by siashes. An identifier used as an 
<identifier component> must be Less than or equal to 10 
characters. 


Examples 
COMPUTER/TTY35 


Basic Components 


cont 


INTEGERS. 


Syntax: 


<integer> :s= <digit> / <integer> <digit> 


Semantics: 


Only positive integers are allowed. 


A space may not app2ar 


within an integer. Integers are Limited to eight digits. 
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Basic Components 


cont 


STRINGS. 
Syntaxs 
<general string> 22:= <string> / <hexadeciagal string> 
<string> s3= <EBCDIC string> / 
<EBCDIC unit string> 
<EBCDIC string> 33:= "<character concatenati on>* 


<character concatenation> :?:= <string character> / 
€<character concatenatton> 
<string character> 


<EBCDIC unit string> s3= "<string character>* / 
“"“<string bracket character>* 


<hexadecimal string> s3= "<hex string>* 


<hex string> 33= <hex pair> / <hex string> 
<hex patr> 


<hex pair> 33= <hex character> 
<hex character> 


<hex character> <2= O /1/7/2/7 3547445764777 BS 
9SASBSCSDSESE 

<hex untt string> 23= <hexadecimal code> ““<hex pair>"* 

<EBCDIC CODE> s3:= B / <empty> 

<hexadecimal code> ss= 4 

<one-byte string> ss= <EBCDIC unit string> / <hex unit string> 


Semantics: 
The maximum length of a string is 120 characters. Strings con- 


taining internat quotes must be broken into separate <strings> 
containing three quotes in succession. 
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Basic Components 


cont 


LOGICAL VALUES. 
Syntax: 

<logical value> *:= TRUE / FALSE 
Semantics: 


A togical value consists of the two possible conditions that a 
Boolean may assume. 


DECK DESCRIPTION 


DECK DESCRIPTION. 
Syntax: 


<DECK DESCRIPTION> 3::= <CONTROL statement> / 
<CONTROL statement> 
<MCSTIC FILE NAME statement> 
<FORMAT FILE NAME statement> 
<GLOBAL section> 
<DEFINITION section> 


Semantics: 


In order to create an MCS with B 1800/8 17090 GEMCODS» the user must 
execute MCSTCL. First the user must toad MCSGTS» MCSGO and MCSTCL 
fron the 8 1800/8 1700 GEMCOS release tape. MCSTCL can then be 
executed by reading in a card deck constructed as fotlows:; 


2EX MCSTCL 
?2DATA MCSIN 


<Deck description> 


2END 


As soon as the compitation begins» MCSTCL reads MCSIN»s and writes 
MCSLST on a Lime printer. MCSLST consists of a listing of the 
<Deck description> along with any syntax errors. If there are no 
syntax errors» MCSTCL takes the actions specified in the <CONTROL 
statement>. 


The user could create and maintain a TCL source file with CANDE 
instead of a card deck. The CANDE default file type should be 


used. To run MCSTCL with ICL source file created through CANDE» 
enter the following: 


EX MCSTCL FILE MCSIN NAME <user‘s CANDE file name> DSK DEFs 
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DECK DESCRIPTION 


cont 


Exaaple: 


2EX MCSTCL 
2DATA MCSIN 
CONTROL = GENERATEs LIST» COMPILE. 
GLOBAL: 
MONITORTRACE = TRUE. 
NCCOXRESPONSE = “"SOK$*. 
CONTROLSTATIONS = TOBOOA. 
BEGIN 
PROGRAM PAYROLL USER: 
TITLE = PAYROLL. | 
TRANCODE = UPDATECLe1).- 
TRANCODE = INQC1is2). 
PROGRAM INVENTORY USERS 
TITLE = INVNT. 
TRANCODE = RCV C201)» SHIP €222).- 
PROGRAM GAME UTILITY: 
TITLE = MAZE/GAME. 
INTERFACE = NONPARTICIPATION. 
STATION TOSOOA: 
STATION TD800B: 
STATION TO8O00C: 
STATION TO7OOA: 
STATIC DECLARATIONS: 
DECLARE 01 MESS-STRUCTURE CHARACTER(5)» 
02 MESS.ITEM.1 CHARACTER(C3)» 
O02 MESS-ITEN.2 CHARACTERC2 Dp» 
ENDSOURCECODE. 
PROCEDURE SETVALUES: 
PROCEDURE MESSeSET.eVALUESs2 
MESS -ITEMe-1 S= "AAA™5% 
MESS.~ITEM.2 s= "BB"32% 
END MESS«SET-VALUESs2Z 
ENDSOURCECODE. 
END. 
PEND. 


CONTROL Statesent 


CONTROL STATEMENT. 
Syntax: 
<CONTROL statement> *:= CONTROL = <controlt List>. 


<controit List> 33= <control task> / 
<coatrot tist> » <control task> 


<controi task> 23= LIST / GENERATE / REGENERATC / COMPILE / 
UPDATEFMT 


Semantics: 


The <CONTROL statement> defines the task(s) to be performed during 
a run of MCSTCL. The <controt tist> defines the individual task 
or combination of tasks. 


LIST causes a hard-copy record of the user's data communication 
System description to be written to a iine printer. The Litsting 
is Labeled MCSRPT. If LIST is the only option in the <control 
list>» the <GLOBAL section> and the <DEFINITION section> are not 
required> however» the MCSTIC fale must be available to MCSTCL. 


GENERATE causes MCSTCL to create a disk file tabetled MCSTMP and 
ZIP MCSGO. MCSG0 uses MCSTMP and MCSGTS to create MCSSRC»s the 
user’®s MCS sourcecode file. In additions when GENERATE appears 
in the <CONTROL statement>» a disk file tabeted MCSTIC is written. 
MCSTIC contains customized tables consisting of the user's data 
communication system network relationships. The MCSTIC file must 
be present when executing a B 1700 GEMCOS~-generated MCS. When 
GENERATE is tn the <controt tlist>» both the <GLOBAL section> and 
<DEFINITION sectiton> must be present. 


REGENERATE causes MCSTCL to create a new MCSTIC fate from an old 
one. This option should be used if a stations transactions pro- 
gram» or access key is to be added or changed. REGENERATE neither 
writes MCSCRD nor ZIPrexecutes MCSGO» thus saving machine tine. 
When REGENERATE is in the <control tlist>» both the <GLOBAL section> 
and the <DEFINITION section> must be present.j If MCSYCL determines 
Cwhile modifying an existing MCSTIC file) that the MCS code file 

is no longer coapattbles tt produces a syntax error and the regen~ 
eration does not occur. This hadpens when» for examples AUDIT was 
not specified in the original GENERATE runs but app2ars in the 
REGENERATE run. 


CONTROL Statement 


cont 


NOTE 
During a REGENERATE rune the station 
network control informations which is 
used to bring stattons back to their 
last running states is not copied from 
the old MCSTIC fite to the new one. 
Therefore» after a regenerations sta- 
tions in the network have those attrico- 
butes specified in NDL which do not 
reflect the accurgulated changes caused 
by GEMCOS Network Control Commands. 
Moreovers the audit file number is reset 
to zeros all existing audit files are no 
longer valid. 


COMPILE causes MCSTCL to instruct MCSGO to ZIP-execute the UPL 
compiler to create MCSSRC/object from MCSSRC. If COMPILE appears 
in the <control List>» GENERATE must also appear. 


UPDATErMT facilitates recoapilation of the FCL FORMAT section 
without requiring generation or regeneration. The format section 
can be recompiled while the MCS ts operating and without affecting 
the MCSTIC fiiee Onty previously coragptied functions and foraats 
can be modified. The recompiled functions and formats are copied 
into the format file» MCSFORMATS. Programs and stations have 
access to the new copy of the format through the *UPD network 
control commands entered froa the controt station or the SPO. 


Examples: 
CONTROL = LIST. 
CONTROL = REGENERATE» LIST. 
CONTROL = GENERATE LIST» COMPILE. 
CONTROL = UPDATEFMT. 


Figures 3-1 through 3°74 ikLlustrate which files are created and 
accessed by the TCL compiler CMCSTCL) when the previously listed 
example control statements are present. 


CONTROL Staterent 


cont 


OPTIONAL) 


Figure 3-1. Files Created by TCL 
Compiler When CONTROL = LIST 


3°15 


CONTROL Statement 
cont 


MCSGO 


oo 
YU 
= 


NCS IN 


Figure 37-2. Files Created by fFCL 
Compiler When CONTROL = 
GENERATE» LIST» or COMPILE 


CONTROL Staterent 


cont 


MCSIN 


MCS TCL 


Figure 3-3. Files Created by TCL 
Compititer When CONTROL = 
REGENERATE or LIST 
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MCSTIC FILE NAME Statement | 


MCSTIC FILE _ NAME. STATEMENT. 
Syntax: 


<MCSTIC FILE NAME statement> 33= MCSTICFILENAME = <file~ID>./ 
<empty> 


Semantics: 


The <MCSTIC FILE NAME statement> allows for the specification of 
the MCSTIC file name.w The <MCSTIC FILE NAME statement>» if pre- 
sents» must appear after the <CONTROL statement> and before the 
<GLOBAL section>.j <File-I0> is a B 1800/ 8 1700 file idantifier. 
By default» MCSTICFILENAME ts MCSTIC. 


Examples: 
MCSTICFILENAME = MYMCSTIC. 
MCSTICFILENAME = TEST/MYMCSTIC. 
MCSTICFILENAME = PACKB/TEST/MYMCSTIC. 


FORMAT FILE NAME Statement 


FORMAT FILE NAME STATEMENT. 


Syntax: 


FORMATFILENAME = <ftle-ID>. / 
<2 apty> 


<FORMAT FILE NAME staterment> ss 


Semantics: 


The <FORMAT FILE NAME statement> is used to change the name of the 
MCSFORMATS file. This statement only functions in the advanced 
and total versions of GEMCOS.j It must timmediately follow the 
<MCSTIC FILE NAME statement> and precede the <GLOBAL section>. 
<File-ID> is a B 1800/B 1700 fale identifier. By default» 
FORMATFILENAME is MCSFORMATS. 


Examples: 
FORMATFILENAME = ALLFORMATS. 
FORMATFILENAME = TEST/FORMATS. 
FORMATFILENAME = GEMPAC/LIVE/FORMATS. 
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GLOBAL Section 


GLOBAL SECTION. 
Syntax: 
<GLOBAL sect ton> 33s= <global definitton> / <empty> 
<global definition> :2= GLOBAL: <GLOBAL statement List> / 
<global statement list> 33s= <GLOBAL statement> / 
<GLOBAL statement tlist> 
<GLOBAL statement> 
<GLOBAL statement> 2s= <CODE GENERATION statement> 


<MISCELLANEOUS PARAMETER stateaent> 


<CODE GENERATION statement> :s= <CHANGE REQUESTS statement> / 
<DATA DUMP statement> / 
<MESSAGE BROADCAST statenent> 7/ 
<MESSAGE RECALL statement> / 
<PROGRAM BOJ EOJ statement> / 
<MONITOR TRACE statement> / 
<STATUS REPORTS statement> / 
<SYSTEM HALT statemant> / 
<COMPILE OPTIONS statement> / 
<OBJECT CODE FILE NAME stateaent> / 
<SOURCE CODE FILE NAME statement> / 
<NAME STACK ENTRIES statement> / 
<VALUE STACK BITS statemant> / 
<CONVERSATIOGNLIMIT statement > 


<MISCELLANEOUS PARAMETER statement> 

>s= <NCC OK RESPONSE statement> / 
<SIGNAL CHARACTER st atemant> / 
<AUDIT RECORD SIZE statesent> / 
<AUDIT PAGE SIZE staterment> / 
<AUDIT FILE PACK ID statement> / 
<CHECKPOINY INTERVAL statement> / 
<MAX TEXT SIZE statement> / 
<QUEUE DEPTH statesent> / 
<QUEUE BUFFERS statament> 7/ 
<QUEUE NAME statement> / 
<SIMULATION statement> / 
<MONITOR TRACE ON statement> / 
<FORMAT AND FUNCTION statement List> / 
<RECALL PROGRAM statement> / 
<CONTROLSTATIONS statement> 


Semantics: 


The <GLOBAL section> is composed of two types of <G.OBAL 
Statements>: <CODE GENERATION statements> and <MISCELLANEOUS 
PARAMETER statements>. <Any given <GLOBAL statement> may only 
occur once in the <GLOBAL section> with the exception of the 
format and function statements. 


GLOBAL Section 


cont 


There are two types of <CODE GENERATION statements>. Firsts there 
are <CODE GENERATION statements> which cause optional MCS intrin- 
Sics to be generated into the MCS source files they can take on a 
true or faise value. Optional MCS intrinsics include code to 
support change commandss the data dump commands message broadcast» 
message recall» prograa control commands» the monitor traces sta- 
tus commandss system shutdowns audit» output audit and queue 
restoration. Second» there are <CODE GENERATION statements> which 
control the nasges of GEMCOS files» UPL compiter options» and object 
code memory size requirements. It is tmportant to note that both 
types of <CODE GENERATION statements> directly affezt the WCS 
source and/or object code files. Therefores if a <CODE GENERATION 
statement> is modified» GENERATE and COMPILE should appear in the 
<CONTROL statement> since new source and object code files are 
requireds otherwise» MCSTCL detects an object code file» MCSTIC 
file incoapatibility error. 


<MISCELLANEOUS PARAMETER statements> specify various attributes of 
arunning GEMCOS MCS such as the signat character» Control sta~ 
tions Network Control Command responses etc. Except for the 

<MAX TEXT SIZE statement>» the <AUDIT PAGE SIZE statement> and the 
<CONTROL STATIONS statement>» <MISCELLANEOUS PARAMETER staterents> 
may be safely changed in a REGENERATE MCSTCL run. 


Example: 


GLOBAL: 
PROGRAMBOJEOS = TRUE. 
MONITORTRACE = FALSE. 
COMPILEOPTIONS = "LIST SINGLE". 
QUEVUEBUFFERS = 3. 
DATADUMP = TRUE. 


GLOBAL Section 


cont 


CHANGE REQUESTS STATEMENT. 


Syntaxs 


<CHANGE REQUESTS statement> 33s= 


Semantics: 


CHANGEREQUESTS = <logical value>e. 


<eapty> 


The <CHANGE REQUESTS statement> determines whether the GEMCOS MCS 
is to contain the Logic to support the following seven Network 
Control Command change requests: 


ae 
De 
Ce 
de 
Ce 
f. 
ge 


When MONITORTRACE equals TRUE» the CHANGE MONITOR FLAG CCMF) 


CHANGE 
CHANGE 
CHANGE 
CHANGE 
CHANGE 
CHANGE 
CHANGE 


STATION 
STATION 
STATION 
STATION 
STATION 
STATION 
STATION 


ADDRESS CCSA). 

DIAGNOSTIC CCSD). 
FREQUENCY CCSF). 

MAXIMUM RETRY CCSM). 

QUEUE (C5Q). 

READY CCSR). 

TRANSMISSION NUMBER CCST). 


command 


becomes the eighth change request and CHANGEREQUEST defaults to 


TRUE. Otherwises 
Example: 
CHANGE REQUESTS 
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= TRUE. 


CHANGEREQUESTS defaults to FALSE. 


GLOBAL Section 


cont 


DATA DUMP STATEMENT. 


Syntax: 


<DATA DUMP statement> *°3= DATADUMP = <logical value>. / <empty> 


Semantics: 


The <DATA DUMP statement> indicates whether the code to create a 
dusp of internat MCS variables is present. I€ DATADUMP equals TRUE» 
the REPORT DATA DUMP CRDM) command is recognized. By default» 
DATADUMP equals FALSE. 


Exasple: 
DATADUMP = FALSE. 
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GLOBAL Section 


cont 


MESSAGE BROADCAST STATEMENT. 


syntax: 


<MESSAGE BROADCAST statemeant> 33= 


MESSAGEBRDADCAST = <fLogicat value>. / 
<eapty> 


Semantics: 


The <MESSAGE BROADCAST staternent> specifies if the code to support 

the BROADCAST (BRC) Network Control Command is to be genarated. By 

defaults MESSAGEBROADCAST equals FALSE. 
Example: 


MESSAGEBROADCAST = TRUE. 


GLOBAL Section 


cont 


MESSAGE RECALL STATEMENT. 
Syntaxs 
<MESSAGE RECALL statement> 32= 
MESSAGERECALL = <logical vatue>. / 
<eapty> 


Semantics: 


The <MESSAGE RECALL statement> indicates whether the code to sup- 
port the POP QUEUE CPQ) Network Control Comrgand willl be generated. 
MESSAGERECALL equals FALSE by defauit. 


Examples 
MESSAGERECALL = TRUE. 
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GLOBAL Section 


cont 


PROGRAM BOJ EOQJ STATEMENT. 
Syntax: 
<PROGRAM BOJ EOJ statement> 33= 
PROGRAMBOJEOJS = <lLogicad vatue>. / 
<enpty> 
Semantics: 
The <PROGRAM BOJ EOJ statement> determines tf the EXECUTE PROGRAM 
CEX)» HALT APPLICATION PROGRAM CHAP)» and CLEAR BUSY FLAG CCBF) 
Network Control Commands are to be supported. By defautt>» 


PROGRAMBOJEOJ equals FLASE. This statement should be set to TRUE 
if Utility Programs are to be generated into the MCS. 


Example: 
PROGRAMBOJEOJ = FALSE. 
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GLOBAL Section 


cont 


MONITOR TRACE STATEMENT. 
Syntax: 


<MONITOR TRACE statement> <*:= 
MONITORTRACE = <logicat value>. / 
<eapty> 


Semantics: 


The <MONITOR TRACE statement> specifies whether to generate logic 

for the Debug Monitor. When MONITORTRACE ts set» CHANGEREQUESTS 
becomes TRUE by default to inctude the CMF Network Controi Command. 
However» if CHANGEREQUESTS equals TRUE and MONITORTRACE equals FALSE» 
the CMF Network Control Comsand is not recognized. By default» 
MONITORTRACE equais FALSE. 


Example: 
MONITORTRACE = TRUE. 


GLOBAL Section 


cont 


STATUS REPORTS STATEMENT. 
Syntax: 


<STATUS REPORTS statement> ::= 
STATUSREPORTS = <logtcal vatiue>. / 
<eapty> 


Semantics: 


The <STATUS REPORTS statement> determines whether to include the 
logic to support the following five Network Controt Command status 
report requests: 


ae REPORT FILE STATUS CRFS).- 

be REPORT PROGRAM COUNTERS CRPC). 

Ce REPORT PROGRAM STATUS CRPS). 

de REPORT STATION COUNTERS CRSC). 

ee REPORT STATION STATUS CRSS). 
STATUSREPORTS equats FALSE by default. 


Exaaple: 
STATUSREPORTS = FALSE. 


GLOBAL Section 


cont 


SYSTEM HALT STATEMENT. 
Syntax: 


<SYSTEM HALT statement> ::= SYSTEMHALT = <logicai vatue>. / 
<empty> 


Semantics: 


The <SYSTEM HALT statement> specifies if the code for handling the 
HALT CHLT) Network Control Command ts to be generated. If SYSTEMHALT 
is set TRUE» CHANGEREQUESTS is set TRUE. SYSTEMHALT equals FALSE 

by default. 


Examples 
SYSTEMHALT = TRUE. 


GLOBAL Section 


cont 


COMPILE OPTIONS STATEMENT. 
Syntax: 


<COMPILE OPTIONS statement> 33= 
COMPILEGPTIONS = <string>. / <ampty> 


Semantics: 


The <COMPILE OPTIONS statement> aditlows for the speci fication of 

UPL compiler control statements when COMPILE appears in the 

<CONTROL statement> Crefer to the Burroughs B 1700 Systems User 
Programming Language CUPL) Reference Manuals form 1067170» for a 
complete description of available options). <String> must begin 

and end with a quote and must not exceed 65 characterse By defauit>» 
COMPILEOPTIONS is set to NO LIST NO_DUPLICATES SUPPRESS USEDOTS. 


Examples: 
COMPILEOPTIONS = "LIST SINGLE*. 
COMPILEOPTIONS = “LIST XMAP XREF". 


GLOBAL Section 


cont 


OBJECT“CODE FILE NAME STATEMENT. 
Syntax: 


<OBJECT CODE FILE NAME statenaent> ::= 
OBJECTCODEFILENAME = <file-ID>. / 
<eapty> 


Semantics: 


The <OBJECT-CODE FILE NAME statement> atitlows for the specification 
of the MCS object code fiie name when COMPILE appears in the 
<CONTROL statement>. <File-ID> is a B 1800/B 1700 file identifier. 
By defaults» OBJECTCODEFILENAME is MCSSRC/OBJECT. 


Exasples: 
OBJECTCODEFILENAME = MCS. 
OBJECTCODEFILENAME = INVENTORY/MCS.~ 


GLOBAL Section 


cont 


SOURCE“CODE FILE NAME STATEMENT. 
Syntax: 


<SOURCE CODE FILE NAME statenent> 33= 
SOURCECODEFILENAME = <ftle-ID>. / 
<eapty> 


Semantics: 


The <SOURCE“CODE FILE NAME statement> allows for the specification 
of the MCS source code file name when GENERATE appears in the 
<CONTROL statement>. <File-ID> is a B 1800/B 1700 file identifier. 
By defaults» SOURCECODEFILENAME is MCSSRC. 


Examples: 
SOURCECGDEFILENAME = €MCS/SOURCE. 
SOURCECODEFILENAME = SOURCE/FILE. 


GLOBAL Section 


cont 


NAME“STACK ENTRIES STATEMENT. 
Syntax: 


<NAME STACK ENTRIES statement> ss= 
NAMESTACKENTRIES = <integer>. / 
<eapty> 


Semantics: 


The <NAME STACK ENTRIES statement> specifies the gmaxinum nuaber of 
name~stack entries that need to be reserved for varaabiles dectared 
by user-written code. Yhis parameter is used to ensure that stack 
sizes are large enough to execute an MCS which contains user-writ- 
ten code.e. If the value assigned in this statement is not Large 
enoughs a name or valuecstack overflow error may ocsur when the 
MCS is executed. Namec-stack entries are used to store inforszation 
concerning variables. One namemstack entry ts used for each data 
name that appears in a <DECLARE statement>.j If a data name refers 
to an array» it requires two name-stack entries. By default» 

NAME STACKENTRIES is set to 0. 


To achieve optimat memory uses» GEMCDS estimates the name~stack space 
required for its variable dectarations and overrides the UPL coapiler 
defaults. If user code is being included» NAMESTACKENTRIES shouwuid 
be set appropriately. The value given to NAMESTACKENTRIES ts added 
to the GEMCOS estimate. If usercewritten code is not included» the 
<NAME STACK ENTRIES statement> may be ignored. 


Examples: 
NAMESTACKENTRIES = 25. 
NAMESTACKENTRIES = 100. 


GLOBAL Section 


cont 


VALUE“STACK BITS STATEMENT. 


Syntax: 


<VALUE STACK BITS statement> 33= 
VALUESTACKBITS = <integer>. / 
<eapty> 


Semantics: 


The <VALUE STACK BITS stateaent> specifies the maxiaum number af 
value-stack bits that are needed as a result of user-code data-name 
declarations. This parameter is used to ensure that stack sizes 
are targe enough to execute an MCS which contains user~written code. 
If the value assigned in this statement is not larg2 enoughs a name 
or value-stack overflow error may occur when the MCS ts executed. 
The value of a variable which requires 24 or less bits requires no 
room on the value stack. However» if a variable requires saore than 
24 bits» or if the variable refers to an arrays spare must be 
reserved on the value stack for that variabie.w By default» 
VALUESTACKBITS equats zero. 


In a fashion simitar to the <NAME STACK ENYRIES statement>s the 
<VALUE STACK BITS statement> enables GEMCOS to achieve optinanized 
memory usee GEMCOS estimates the value~stack space required for 
its variables and overrides the UPL compiler defautts. If user 
code is includeds VALUESTACKBITS should be set appropriately. The 
number assigned to VALUESTACKBITS is added to the GEMCOS esti- 
mates. If user~written code ts not itnctuded»s the <VALUE STACK 
BITS statement> may be tgnored. 


Examples: 
VALUESTACKBITS = 1000. 
VALUESTACKBITS = 256. 


GLOBAL Section 


cont 


CONVERSATIONLIMIT STATEMENT. 
Syntax: 


<CONVERSATIONLIMIT statement> *:= CONVERSATIONLIMIT = <integer> / 
<empty> 


Semantics: 


The <CONVERSATIONLIMIT statement> allows the user to specify the 
maximum number of stations that may converse concurrently. The 
integer specified must not exceed the number of stations declared 
in TCL. The maxinum Limit aliowned by GEMCOS is 64. If there are 
no CONVERSATIONSIZE statements declared for programs in the TCL» 
the defauit value is zeroe That iss no conversation capability 
exists in the MCS. If conversational prograss are present» the 
default value its the number of stations declared in the TCL. If 
zero is declared» no conversation capability exists in the MCS. 


This statement establishes the number of reserved conversation 
arease The number of areas are reserved by powers of 2. When the 
limit is declared» the nearest 2 to the nth power that is greater 
than or equal to the Limit ts the number of areas reserved. Even 
if the reserved area is targer than the Limit» the maxinus nusber 
of concurrent conversations may not exceed the specified lLimnit. 

If the limit needs to be increased and the new Limit exceeds the 
number of reserved areas» a GENERATE. and re~COMPILE is r2quired. 


Examples: 
CONVERSATIONLIMIT = 8. 
CONVERSATIONLIMIT = 5. 


GLOBAL Section 


cont 


NCC GOK RESPONSE STATEMENT. 
Syntaxs 


<NCC OK RESPONSE statement> :3s= NCCOKRESPONSE = <string>. / 
<empty> 


Semantics: 


The <NCC OK RESPONSE statement> defines the message to be returned 
to a station upon successful completion of a Network Controt Coa- 
mand. The <string> must begin and end with a quote and cannot 
exceed eight characters in dength. By default» NCCRESPONSE is & 
(dollar sign). 


Exasples: 
NCCOKRESPONSE = "NCC OK". 
NCCOKRESPONSE = “DONE*. 
NCCOKRESPONSE = "aQKe™, 


GLOBAL Section 


cont 


SIGNAL CHARACTER STATEMENT. 
Syntaxs 


<SIGNAL CHARACTER statemant> 33= 
SIGNALCHARACTER = <character>. / 
<eapty> 


Semantics: 


The <SIGNAL CHARACTER statenent> defines the character whichs when 
encountered in the first position of a message» signais the Net- 
work Controller and the MCS that the message is a Network Control 
Command. The character sust be a singte character enclosed in 
quotes. By defaults SIGNALCHARACTER is “*#". 


Exaaple: 
SIGNALCHARACTER = "2*. 


GLOBAL Section 


cont 


AUDIT RECORD SIZE STATEMENT. 


Syntax: 


<AUDIT RECORD SIZE statement> :3= AUDITRECORDSIZE = <intager>. / 
<enapty> 


Semantics: 


The <AUDIT RECORD SIZE statement> controls the size of the audit 
record by specifying the nuaber of bytes in each rezord. Inmcresents 
of 180 are the only allonable values. If a vaiue other than an 
increment of 180 is specified» a warning is tssued and the next 
highest increment of 180 is selected. By defaults» AUDITRECORDSIZE 
equals 180. 


Examples: 
AUDITRECORDSIZE = 180. 
AUDITRECORDSIZE = 540. 


GLOBAL Section 


cont 


AUDIT PAGE SIZE STATEMENT. 
Syntax: 


<AUDIT PAGE SIZE statement> *:= AUDITPAGESIZE = <integer>. / 
<empty> 


Semantics: 
The <AUDIT PAGE SIZE statement> controts the size of the audit 


files by specifying the number of records in each page (t.e.» area). 
There are always 40 pagese By default» AUDITPAGESIZE equals 10000. 


Examples: 
AUDITPAGESIZE = 500. 
AUDITPAGESIZE = 2000. 


GLOBAL Section 


cont 


AUDIT FILE PACK ID STATEMENT. 
syntaxs 


<AUDIT FILE PACK ID staternent> :2:= AUDITFILEPACKID = <identifier>. 
4 <empty> 


Semantics: 


The <AUDIT FILE PACK ID statement> allows MCS audit files te re- 
Side on other than the system packe It is recommended that audit 
files reside on a user pack to increase throughput and decrease 
the time spent in audit and recovery. Identifier aust be 10 
characters or less in length. By default» audit files reside on 
the system pack. 


Examples: 
AUDITFILEPACKIOD = MCSPACK. 
AUDITFILEPACKID = AUDITPACK. 


GLOBAL Section 


cont 


CHECKPOINT INTERVAL STATEMENT. 


Syntax: 


<CHECKPOINT INTERVAL stateaent> 3:= CHECKPOENTINTERVAL = <integer>. 
f <eapty> 


Semantics: 


The <CHECKPOINT INTERVAL statement> determines the Length of tise 
between checkpoints taken by the MCS during auditing. Specifying 
too small a number causes the MCS to do an excessive number of 
I/Os» thereby reducing throughput. By defaults» CHECKPOINTINTERVAL 
equals 60 (seconds). 


Examples: 
CHECKPOINTINTERVAL = 30. 
CHECKPOINTINTERVAL = 90. 
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GLOBAL Section 


cont 


MAXIMUM TEXT SIZE STATEMENT. 


Syntaxs 


<MAX TEXT SIZE statement> *23= MAXTEXTSIZE = <integer>. / 
<eapty> 


Semantics: 


The <MAX TEXT SIZE statement> defines the sizes in tharacterse of 
the longest message that can pass through the MCS. MAXTEXTSIZE 
has a direct affect upon the memory requirements of a GEMCOS MCS. 
It 3s best to keep MAXTEXTSIZE as low as possibie. If the MCS has 
AUDIT specified as TRUE» the user should never atteapt to change 
MAXTEXTSIZE in a REGENERATE MCSTCL runs otherwises old audit files 
will have an incompatible record length. Moreover» an increase in 
MAXTEXTSIZE usuattly causes a GENERATE and COMPILE to be required 
so that the MCS can have a larger vatue stack. If AUDIT ts FALSE» 
MAXTEXTSIZE can be safely lowered on a REGENERATE MCSTCL run. The 
default value for MAXTEXTSIZE is 125. 


When formatting takes places resultant messages may contain con= 
trol characters such as tabs» carriage returns» etce Each controi 
character takes up one or more positions tn the formatted message. 
An allowance for these characters must be reflected by 
MAXTEXTSIZE. 


Examples: 
MAXTEXTSIZE = 1920. 
MAXTEXTSIZE = 300. 


GLOBAL Section 


cont 


QUEUE DEPTH STATEMENT. 
syntax: 
<QUEUE DEPTH statement> *:= QUEVEDEPTH = <integer>. / 
Semantics: 
The <QUEUVUE DEPTH statement> specifies the number of messages which 


may be outstanding in the queue for the MCS. <Integer> say range 
from 1 to 1023.2 By defaults» QUEVEDEPTH equals 290. 


Examples: 
QUEUEDEPTH = 5. 
QUEVEDEPTH = 75. 
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GLOBAL Section 


cont 


QUEUE BUFFERS STATEMENT. 


Syntaxs 


<QUEUE BUFFERS statement> ::= QUEVUEBUFFERS = <integar>. / 
<eapty> 


Semantics: 


The <QUEVUE BUFFERS statement> specifies how many memory buffers 
are available to the MCS queue before messages begin to overflow 

to disk. The value assigned to QUEUEBUFFERS directly affects the 
memory requirements of the onwtline system. <A vatue too small or 
too large can degrade system throughput. It ts suggested that the 
user experiment with this statement to find the most efficient 
value. QUEUEBUFFERS must not have a value greater than QUEUEDEPTH. 
<Integer> may range from 1 to 16.2 By defaults» QUEUE BUFFERS has 

the vatue 1. 


Exaapless 
QUEUEBUFFERS = 5. 
QUEVEBUFFERS = 8. 


GLOBAL Section 


cont 


QUEUE NAME STATEMENT. 
Syntax: 


<QUEUE NAME statement> °::= QUEUENAME = <rermote file-ID>. / 
<eapt y> 


Semantics: 


The <QUEUE NAME statement> specifies the external file name of the 
MCS queue (%.e.e» the remote file opened by the MCS). <Remote 
file-ID> should appear in a FILE statement in the user*s Network 
Definition Language source deck. MCSQUEUE is the default value of 
QUEUENAME. 


Example: 
QUEVENAME = MCSRMT. 


GLOBAL Section 


cont 


SIMULATION STATEMENT. 


Syntaxs 


<SIMULATION statement> 3:= SIMULATION = <lLogical value>. / 
<empty> 


Semantics: 


The <SIMULATION statement>» when sets» causes the MCS to open a 
queue file instead of the usual remote file. The progrargm MCSSIM 
can be used instead of the Network Controller to simulate input 
via the card reader. Output is sirmutated to a line printer using 
the MCS Monitor [Trace code. The source code for MCSSIM is MCSIMS. 
SIMULATION equals FALSE by default. 


Exaaple: 
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SIMULATION = FALSE. 


GLOBAL Section 


cont 


MONITOR TRACE ON STATEMENT. 
Syntax: 


<MONITOR TRACE ON statement> 33= 
MONITORTRACEOGN = <logical value>. / 
<eapty> 


Semantics: 
The <MONITOR TRACE ON statement> allows the user to set or reset 


the debug monitor flags enabling the initialization procedure to 
be traced. By defaults» MONITORTRACEON equals FALSE. 


NOTE 
The CMF command can be used to set or 


reset any or ait of the monitor flags as 
soon as initialization is complete. 


Example: 
MONITORTRACEON = FALSE. 
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GLOBAL Section 


cont 


FORMAT AND FUNCTION STATEMENT LIST. 
Syntax: 


<FORMAT AND FUNCTION statement List> 
23= <function dectaration tist> 
<format declaration tist> / 
<enpty> 


<function dectaration List> 2:= <function declaration> / 
<function declaration list> 
<function declaration> / <eapty> 


<format declaration list> 33= <format dectaration> / 
<format dectlarattion list> 
<format declaratton> 


Semantics: 


In addition to the functional capabilities of the basic version of 
B 1800/B 1700 GEMCOS»s> the advanced version includes a Message For- 
matting module. The Message Formatting module can be us2d to 
support forms requests» modify the test of messages» and/or ensure 
Application Programa device independence. Users of the Basic Ver- 
sion will find that an attempt to invoke the formatting 
capabilities of GEMCOS results in a syntax error. 


The Forms Request function provides station operators with the 
ability to enter a <message~ID> (refer to <DEVICE secttion>) and to 
receive in return a formatted screen with blank data fields. 
Application Programs may also invoke the Foras Request function 
causing formatted screens with blank data fields to be displayed 
at stations in the network. 


The text of messages entered at stations can be modi fied» re-arranged 
and/or supplemented prior to being routed to the appropriate 
Application Program. This process is referred to as input format= 
ting. The text of messages written by Application Programs can be 
modified» re~arranged and/or ptaced into data fieids of formatted 
screens before being sent to stations and are referred to as out- 

put formatting. 
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When a network is comprised of two or sore types of tersinal 
devices» the stations may be grouped into several device classifi- 
cations in the <DEVICE seaction> <A set of formats is defined for 
each device classification. When invokeds the formatting asodule 
recognizes the device classification of the station involved and 
appiies a format from the set associated with that slassification. 
As a result» messages sent or received by Application Progrargs can 
have a standard record Layout regardless of the device type of the 
destination/source station. Moreovers the Application Program need 
not be affected by the different control characteristics of different 
devices. 


There are two areas of the Transaction Control Language which 
relate to formatting: the <DEVICE section> and the <FORMAT AND 
FUNCTION statement tist>. The <DEVICE section> is used to identi~ 
fy which messages are to be formatted and with which formats. The 
<FORMAT AND FUNCTION statement List> is used to define formats and 
functions. <A format specifies how a screen its to be built and/or 
how the message text is to be modified.j A function defines a 
transtate table which can be referred to by a format. 


The <FORMAT AND FUNCTION statement List> is composed of a 


<function declaration List>» which can be <eapty>» followed by a 
<format declaration tlist>. 
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FUNCTION DECLARATION. 


Syntax: 


<function dectlaration> 2::= FUNCTION <function part List>. 


<function part List> 33= <function part> / 
<function part List> » <flunction part> 


<function part> 33= <function identifier> 
<justification and fit part> 
C<transtlation List>) 
<function identifier> :3s:= <identifier> 


<translation list> 23= <translate pair> / 
<transtlation tist> » <transtate pair> 


<transiate pair> 33= <external string> 3: <internal string> 
<external string> ss= <string> 
<internal string> 23= <string> 


<justification and fill part> 
s3= {EXTERNAL: <function type> » INTERNALS: 
<function type>] / <empty> 


<function type> ss= INTEGER 7 ALPHA / UNEDITED 


Semantics: 
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The <functton declaration> defines functions which :an b2 used in 
a translate <item phrase> of a <format declaration>. A <function 
identifier> is required as the first argument of the translate 
<item phrase>. fhe translate <item phrase> atltows a foraat to 
translate a string of length n into a string of length m where 
O<n<7 and O<a<7. <String> ts therefore Limited to a maximun of 
Six characterse Up to 1023 functions may be dectarad. 


A <transtate pair> associates an <external string> with an 
<internal string>. On input» an <external string> is translated 
into the associated <internal string>. On outputs an <internal 
string> ts translated into the associated <external string>. When 
an Application Program deals with the text of a message» it must 
use an <internal string> in a translate field. dhen an operator 
deais wath the text of a message at a stations an <axternal 
string> is used. 
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Refer to FORMAT DECLARATION for examptes of FUNCTIONS used in 
FORMAT. 


The <justification and fill part> is described in the following 
exaaple: 


Example: 


FUNCTION GENDER C"MALE"S"1%» “FEMALE™S"2"). 

FUNCTION DIGITIN C*™1"S"ONE">» "2"S"THO"%> "3" "THREE )>» 

DIGITOUF CEXTERNALSALPHA» INTERNALS INTERNALSINTE GERI 
C"ONE*S "1%, “TWO"S"2"> "THREE*2"3"). 


As the translate module searches for a match between the source 
text to be translated and an <internal string>/<external string>» 
both the source text and the <internal string>/<external string> 
are piaced tnto character strings of Length stx for comparison. 
The <justification and fill part> enables the user to control the 
placement of the source text and the <itnternai string>/<2xternal 
string> into these character strings. If the <justi fication and 
fill part> is <empty>» it is assumed that both the <external 
string> and <internai string> are unedited. By using the 
<justification and fill part>» the user may make either of these 
Strings UNEDITED» INTEGER» or ALPHA. 


An UNEDITED string of less than six characters in length ts right 
justified within a 6-character string with leading nutts (4700). 
A null compared with any character is always considered a true 
comparison by the transtate function. 
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cont 


An integer string of less than six characters is right justi fied 
with leading zeroes. An atpha string of Less than six characters 
is left justified with trailing blanks. 


If within a given functton the Length of each <internal string> is 
the same and the length of each <externatl string> is the sames it 
makes little difference whether the strings are UNEDITED» INTEGER» 
or ALPHA. Howevers if striags vary in Lengths using INTEGER or 
ALPHA strings can help to avoid confusion. For examples suppose a 
function is declared as foitlows: 


FUNCTION FEST CPLA" S"SOME"»> “"A"S"ME™). 


Upon inputs if the translate function were to search for an 
<external string> of ls it would get a match with Li because of a 
NNNNN1. The source text after justification will compare as equal 
to NNNNAl»s the <external string> after justification Cwhere N is a 
nutli). A samilar phenomenon would occur on output if the trans-~ 
late function was searching for an <internal string> of ME: 

NNNNME would match NNSOME. This probtem could be avoided by 
declaring the function as follows: 


FUNCTION TEST CEXTERNALZ INTEGER» INTERNALS ALPHAI 
C"™LI"S"SOME">» "17S "ME*). 


With this declaration» if the source text to be transtated on 
input were "1"%» it would be converted to 000001. [It would not 
match 000011» but would successfully match 1 justified as an 
integer. Likewise» source text on output of ME would be converted 
to MEBBB Cwhere 8B is a bDlank)s it would not match SJMEBBs but 
would match ME justified as an alpha string. 
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FORMAT DECLARATION. 


Syntax: 
<format deci arattion> 23= FORMAT part tist>. 
<format part list> 2s= <forsgat part> / 
<format part tist> » <forsat part> 
<format part> 2s= <format identi fier> 
<speciai action part> 
<format description> 
<format identi fier> :3= <identifier> 
<special action part> 2= {<spectal action>}] / <aapty> 
<special action> 23s= RESIDENT 
<format description> ss= (<local declaration part> 
<editing specifications>) 
<locai dectaration part> 33= VARIABLE 
<yariable deciaration List>»s / 
<eapty> 


<vartable declaration List> 33= <variable dectaration> / 
<variable declaration>» 
<variabie deciaration List> 


<variable dectaration> 23= <yariable identifier> 
: <optional toration specifier> 
FOR <integer> 
<variable identi fier> ss= Vi / V2 4/ V3 4 V4 4V5 47 V6 
<optional location specifier> *s:= 2 <integer> / <empty> 
<editing specifications> 23= <editing phrase list> 
<editing phrase list> 33= <editing phrase> / 
<editing phrase list> » 
<editing phrase> 
<editing phrase> s3= <editing string> / 


<item phrase> / 
<location specifier> 


<location specifier> 23= 2 <sign> <integer> 
<sign> 33= + / - / <eapty> 
<editing string> 33= <simple string> / <skip fieid> 
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<skip fietd> 23s= X <integer> / X(€<delimiter>) 


<item phrase> s3= <repeat part> <itam type> 
<fietd width> / 
<repeat part> 
(<editing phrase list>) / 
T(C<function identi fier> » <item type 
<field width> » <internal size>) 


<repeat part> s3= <integer> / 
<update variable> 
<variabie tdentifier> or <integer> / 


<empty> 
<update varitable> 3s= <variable identifier> : / <eapty> 
<item type> ss= ASSIS Bs J 
<function designator> ss= <identifiter> 
<field width> 33= <integer> / 


(<varaabtle field specifier>) 


<variable field specifier> s2:= <delimiter> » <internal size> 
<internat size> 23= <integer> 
<delimiter> 23= <EBCDIC wnit string> / 


<HEX unit string> 


<simple string> s3= <EBCDIC code> <EBCDIC string> / 
<hexadecimal code> 
<hexadectmai string> 


<hexadecimal string> 33= "<hex string>* 
<hex string> 33= <hex pair> / <hex string> <hex pair> 
<hex pair> s3= <hex character> <hex character> 
<hex character> 23= O7LS/SA2AS SFA SSS GESTS 
B/S IOSASBSCSOSESE 
<hex unit string> 33= <hexadecitmal code> “<hex pair>* 
<EBCDIC code> 23= 8 / <empty> 
<hexadectmal code> ss= 4 
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Semantics: 


The <format dectaration> is used to define how a screen is to be 
buiit and/or how message text is to be modified. When formats are 
declared in the <format declaration>» the <DEVICE saction> is used 
to indicate which formats are to be applied to which messages. Up 
to 1023 formats may be declared. 


The <format part tist> altows several formats» separated by consas» 
to be described in a single <format declaration>. cven though the 
syntax allows severai formats to be described in one <format 
declaration>» it is good practice to define one format per <format 
declaration>. When a syntax error ts encountered in a <forsat 
part>» the TCL scanner skips past any remaining <format parts> to 
the next <format declaration>. Syntax errors in the skipped 
<format parts> are not flagged until the <format part> in error is 
corrected. If one format is defined per <format declaration>» 

more syntax errors can be caught in each run of the TCL coapiier. 


Each <format part> associates a <format identifier> with a parti- 
cular set of message formatting instructions. The <format identi- 
fier> is referenced in a <FORMATSIN statement> and/or a 
<FORMATSOUT statement> of the <DEVICE section>. 


The <special action part>» if presents indicates whether the 
format is a resident format. A resident formsmat ts kept in an 
array in memory instead of on diske This facility is provided for 
smalls frequently used formats.j [It ts intended to save the input/ 
output overhead that would otherwise be required to retrieve a 
format from disk before using it. This option should be used with 
care since its overuse couid require significant amounts of 
memory. 


The <format description> consists of an optional <focat 
deciaration part> and the <editing specifications> enclosed within 
parentheses. Refer to <repeat part> under Editing Specifications 
for a discussion of the <local declaration part>. (Readers 
unfamiliar with GEMCOS formatting should refer to BASIC GEMCDOS 
FORMATTING PRAGMATICS before continuing.) 
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The <editing specifications> describe the order and tength of the 
fields of a message as welt as the manipulation of the message 
buffer pointers. The <editing specifications> is a list of 
<editing phrases>-e An <editing phrase> can be an <editing string>» 
a <location specifier> or an <item phrase>. 


An <editing string> is eitther a <simple string> or a <skip field>. 
The <siaple string> is used to place a literal field into a 
formatted messagee A <sinple string> can be an <EBCDIC string> 
such as "XYZ" or a <hexadeciaal string> such as 4700" Ccarriage 
return). The <simple string> $s used extenstvely when building 
forms for screen devicese It can be used to create the descrip~ 
tive text of the protected areas as weii as the necessary control 
characters. <A <simple string> causes the pointer into the for- 
matted message buffer to be updated to the right by the length 

of the stringe The pointer into the source message buffer is 
unaffected by a <simple string> <editing phrase>. 


Upon input the <skip field> causes text in the teraginalt message 
buffer to be skipped (by updating the terminal message buffer 
pointer). The number of characters skipped can be defined by an 
<integer> or a <delimiter>. For examples X3 causes three charac 
ters to be skipped while X("»") causes text up to and including 
the next comma encountered to be skipped. 


Upon outputs X8 causes eight spaces to be placed into the terminal 
message buffer while updating the pointer. X(€<deliaiter>) is 
undefined for output messages.- The program message buff2ar pointer 
is unaffected by a <skip field>. 


The <lLocation specifier> is used to manipulate the program message- 
buffer pointer without affecting the terminal message-buf fer 
pointer. By mantpulating the program message~buffer pointer> 
fields can be skipped» re-ordered and/or re-used. There are two 
variations of the <tlocation specifier> differentiated by the 
existence of an optional <sign>. When a <sign> is presents the 
program message~buffer pointer is adjusted by <integer> positions 
to the left (<sign> ts a "*-") or to the right (<sign> ts a *#"). 
If there is no <sign>» the program message ~buf fer pointer is set 
to position <integer>. Care must be taken to keep the pointer 
within the bounds of the program message buffer. Upon inputs the 
user should aiso be careful not to overlay good data in the 
program message buffer. 


An <item phrase> defines a fietd of a formatted messagee A fieid 
can be comparatively simpie such as six alphanumeric characters» 
or rather comptex»s such as a repetition of several variable-length 
subfieids. In order to encompass the wide variety of possible 
fields» several forms of the <item phrase> are available. Alt 
involve at Least one <item type>» <field width> pair. 
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The <item type> determines how a field or subfield is to be 
edited. Four <item types> are available: A» Bs I and Je A 
denotes an alphanuaseric field» and B specifies a tabbed alphanu- 
meric field. Alphanumeric fields may contain any characters» and 
leading blanks are considered significant. Truncation or blank 
filding occurs on the right. I denotes an integer field while J 
specifies a tabbed integer field. Integer fields may only contain 
digits and/or blanks except for imbedded blanks. They are trun- 
cated or right justified with zero fitting on the left. 


The <field width> deteraines the length of a field or subfield. 
Fields can be fixed or variable in Length. 


The sitiraptest form of the <item phrase> is an alphanumeric or 
integer field with an <integer> <field width> such as A6 or I9. 
An A6 <item phrase> would result in the move of six characters 
from the buffer contatning the raw message to the formatted ses- 
sage buffer. An <item phrase> of I9 would move nine characters 
Subject to the editing rules already mentioned.j JTh2 unprotected 
areas of formatted screens are usuaily composed of fixed alpha- 
numeric or integer fields. 


A more powerful form of the <item phrase> employs a <variable 
fieid specifier> <field width> such as AC"#"s6) or I[(%#"%s8). The 
<internal ssize> determines the stze of the field tin the progran 
message buffer. 


NOTE 
While fitetd itengths of the terminal 
message buffer may vary» fietd lengths 
of the program message buffer are always 
fixed. fhe <delimiter> is used to 
Signify the end of the field in the 
terminal message buffer. The field 
begins where the previous field ends. 


Upon inputs a variableclength field is isolated based on the end 
of the Last field and the <delimiter>. It is moved into the pro- 
gram message buffer justified according to the <item typ2>. The 
<detimiter> is not considered one of the characters of the field 
ands therefore» is not placed into the program message buffer. 


Upon outputs a string of characters of length <internal size> is 
obtained from the program message buffer. It ts compressed by 
truncating trailing bianks or leading zeroes depending on the 
<item type>.j The compressed string is placed into the tarainal 
message buffers» and the <delimiter> is tnserted after tha 
compressed string. 
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During both input and output» the terminal message buffer is 
updated to the position following the <deliniter>s» while the pro- 
gram message buffer is moved to the right by <internat size> 
positions. 


Tabbed fields» where the <item type> is *B" or *J"»s are similar to 
variable-tLength fietds on input and the same as fixed fields on 
outpute Input» a tabbed field can end early if the tab character 
(€4"05") is encountered. However» unlike a variable fieid»s where 
the <delimiter> must be present» the tab character is not required 
to end the field. If enough characters are founds the field ends 
automaticatly. For examptes a B10 <item phrase> on input causes 
characters to be moved from the terminal message buffer to the 
program message buffer until either ten characters have been 

moved or a tab character is encountered. The program message~ 
buffer pointer is moved ten characters to the righte. The terminal 
message~buffer pointer is left pointing to the eleventh character 
or to the character following the tabs whichever happens first. 

If the transfer is terainated by a tab characters trailing blanks 
are placed in the program message buffer to fill out atl ten 
character positions. The tab character is not placed into the 
program message buffer. 


Upon outputs 85 would achieve exactly the same results as A5 and 
J7 would behave the same as I7- The tab character is not placed 
into the terminal message buffer as is done with the <delaniter> 
of a variable-lengths- nontabbed field. 


The default tab character (€4"05") can be changed by using a 
<varitable field specifier> along with the B or J <ttem type>. 

J C"*#",5) is the same as J5 except that “%*" is the tab character 
instead of 4"05". 8C4"05"»r10) is identical to 810. 


Each <item phrase> discussed thus far may be repeated by placing 
a <repeat part> in front of the <item type>.j A <repeat part> may 
be fixed or variable. 


A fixed <repeat part> is designated by an <integer>. It ts a 
shorthand method of representing an <editing phrase list> where 
each <editing phrase> is identical. For examples 2A6 is the same 
as AbBsAGbB. 


A variable <repeat part> can only be used on output. It is useful 
for messages which have a variable number of fields of repeated 
data such as taoles with columns of valuese These messages must 
haves as one of the data fields» a counter specifying the number 
of times a particular field wiil occur. 
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If a message is to contain a variable <repeat part>» the foraat 
applied to the message must have a <tocalt declaration part>. The 
<local declaration part> specifies where in the message the 
counters governing the occurrence of the repeated fietds are to be 
found. Vatues for variables declared are the first items 
extracted from the program sessage buffer. During each variable 
assignment» the program message~buffer pointer ts adjusted by a 
combination of the <optional location specifier> and the tength of 
the counter field. The length of the counter field ts detersined 
by the <tnteger> following the keyword FOR.j The value of the 
counter contained in the program message buffer must be expressed 
as EBCDIC digits with a value not greater than 255.2 As many as 
six variables can be declared per format. 


After a local varsable has been set to a value extracted froa the 
program message buffer» it can be referred to as a <varitable 
tidentifier> in a variable <repeat part>. A variable <repeat part> 
consists of an optional <update variable>» a <wariabple identifier>» 
the keyword OR and an <tnteger>. The object of the <repsat part> 
is repeated either the number of ttmes referred to by <variable 
identifier> or <integer> times» whichever is tess. If the <update 
variable> is presents its variapte identifier is set to <variable 
identifier> minus the number of times the repeat object was 
repeated. For exanples V2 or 8 would cause its object to be 
repeated V2 times» but not more than eight times. If V2 had a 
value of nines V¥3:V2 OR 3A5 would cause A5 to be repeated three 
times and V3 would be set to 6. The original value of V3 is tost. 
If V2 had been zeros the AS field would not occur and V3 would be 
set to zero. 


An <editing phrase list> enclosed in parentheses is an even aore 
complicated <item phrase>. This form can be thought of as a field 
composed of several subfields. An <editing phrase List> enclosed 
in parentheses can be the object of a <repeat part>.j <Editing 
phrase tists> can be nested to 32 levets of parentheses. 


Another coaplicated form of the <item phrase>»s» (<function 
identifier>» <item type> <field width>» <internal size>)» is a 
reference to a transtate function. The <function itdentifier> 
refers to a function which must have been defined in a <function 
deciaration>. The <item type> <field width> describes a fietd in 
the terminal message buffers while <internal size> describes a 
fieid in the program message buffer. 
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FORMATTING ERRORS. 

When an error is detected while formatting an input message» the MCS 
sets the format error field of the Common~warea header to a nonzero 
value as described below. The message is then sent to the application 
program for which it was bound. 


When an error is detected while formatting an output messages the MCS 
message is still sent to the destination stations but» in additions an 
error message is sent to the control station specifying uhat type of 
error occurred. 


Error _Type Description 


Destination pointer out of bounds 

Source pointer out of bounds 

Nondigit tn integer field 

Missing skip delimiter 

Attempt to use variable repeat on input 
Missing delimiter or variable field too long 
Invalid string in translate field 
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Only the first error encountered is reporteds however» the MCS attenpts 
to continue formatting a bad messagee When a type~3 formatting error 
occurss the nondigit is placed into the erroneous field.j For type-6 
errorss significant text may be truncated in an atteagpt to force exces= 
Sive data tnto the program message buffer. Type~7 errors result in 
question marks being placed tnto the erroneous field. Results are 
undefined for the other types of errors. 


Tables 3-1 thru 3°75 list five graded examples Cexample sats i thru 5) 
of three increasingly difficult formats applied to tnput messages and 
output messages. 


Example set 5 (table 3-5) uses the following function declarations: 


FUNCTION GENDERC™ MALE*2"°1"%>»"FEMALE"™3"2"). 

FUNCTION NUMIC"ONE*S 91" "THOT EM 2" > "THREE" S"3%5"F QUR™S 74" > 
FIVE sto MST XS "Oe "SEVENV SE" 7 "o"ELGHT*S" 8%» 
"NINETS "9" >" TEN" S"10%o "ELEVEN" 2711 %>» 
"TWELVE": "12"). 

FUNCTION NUM2 CEXTERNALSALPHAs INTERNALS INTEGER) 
C™ONE*S"2 "eo "THOS "2" eo "THREES *3"%59"F QUR®S°h" >» 
"FIVE SP oto PSIX* S67 oe "SEVEN" S97 "eo" EIGHT ™3" 58% > 
"NINE" S "9" s"TEN*S"10">"ELEVEN™2"11 "> 
"TWELVE" >"12"). 

FUNCTION DAY C°L"S "SUN 2 "27S "MONT MS*S "TUES "4h7S “WED” » 
WOM SV" THUTS "67S "FRIWe "773 "SAT"). 
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<Editing specif ications> 


Message As It 


Input/ Appears at the Applied to Mess age Appears to the 
Qutout ~__Lerminal __._____1o_[fansit. s(t LU or Progran_ 
Input/ ABCI234XY A3pIT4eA2 ABC1234XxY 
Output 
Input ABC 4xY A3SsT4eA2 ABC OOO4XY 
Input ABC 4 XY AZeI4eA2 ABC COO04XY 
Input/ ABCOOQO4XY A3eIT4eA2 ABC OO004XY 
Output 
Input AB 5678XY A3Z»X4nA2 AB XY 
Input AB GGGGXY AzeX4oA2 AB XY 
Input/ AB XY AzeX4,A2 AB XY 
Cutput 
Input ABCDE AZe*«", A353 AB*CDE 
Input AB*CDE AZo Sx", A3 AB*«*CD 
Output AB*xCDE A2s™x™, A3 ABC DE 
Input RIGHT A5,8"FACE™ RIGHTFACE 
Cutput RIGHTFACE A5,8"FACE™ R IGHT 
D 
Output NAME = CHARRYIC "NAMES £%5 AS o* 1% 54"%12% HARRY 
2 
D 
Output Name: f{ JC "NAMES C%,A5 5% I%5,4"12" (forms request ) 
2 


Example Set 1 = Formatting 
Specifications Applied to 
Input and Output Messages 


Figure 3-4. 
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Message As [It <Editing specifications> Message As It 


Input/ Appears at the Applied to Message Appears to the 
Qutout ~-Lerainas in_Icans it a me 
Input L12354XY 16 123 4XY 
CFMTERR set to 2) 
Output L2354XY 16 123 4XY 
Ccontrot statton 
notified of 
error) 
Input/ ABCDXYZ QhvAbo dls A3 XYZABCOD 
Output 
Input/ ALPHA 235A5 ALPHA 
Output 
Input/ AB123XY456 A2xdSel 3e 235 0A Ze 28 oI 3 A8xY123456 
Cutput 
Input/ ABCD ZA2 ABCD 
Output 
Input/ AB12CD34 2CA2e 12) A812CD34 
Output 
Output 01/28/52 I292C"/"» 12) 012852 
Input 01/28/52 I2e2CX1 I 2) 012852 
Output * AB COD’ EF Vartabte vil for 25 0O3AB8CDEF 
Wex"*,V1l or 5SCX2sA2) 
CQutput XX 12 3YY 4 5 Variable V1 37 for 2», XXYY000512345 


v2 25 FOR 2s ale 
A2ea9oV22 VL or 3CXLlsIl)» 
23-A2Z20912 V2 or 3CX1lsi1) 


Figure 3-5. Example Set 2 - Formatting 
Specifications Applied to 
Input and Output Messages 
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Message As [It <Editing specifications> Message As It 


Input / Appears at the Applied to Message Appears toa the 
Qutput ~__lerminat  o....JIn_ Transit. 4... _User Prograa_ 
Input/ 15P IC "P*%»5) 00015 
Output 
Input/ Ew A(*#"%,53) E 
Gutput 
Input/ Ex 15P AC*H"™,3),5 IC *P%55) E 00015 
Cutput 
Input ABCDEFGt AC +" 94) ABCD 
CFMTERR set to 6) 
Input 12345 *AB TC%#%o4)e AZ 1234AB 
CFMTERR set to 6) 
T 
Input ALB2Z2AXYZ 86,83 AlB2 xYZ 
8 

Input ALB2C3xXYZ B6.83 A1LB2C3xYZ 

T 
Input A1LB2C3AXYZ 86,83 A1B2C3 

B 

T T 
Input 12Z2A34A 25 0001200034 
8 8 

T 
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BASIC GEMCOS FORMATTING PRAGMATICS. This discussion att2 apts to 
explain the basic concepts of forasattinge. It should prove heipful to 
the user who has not yet workad with GEMCOS formatting. 


The MCS uses two buffers when formatting a message: one buffer con- 
tains the message as it appears at the terminals the other contains 

the message as it appears to the Application Program. A message con- 
sists of a sequence of one or more fields just as a disk» tape or card 
record is composed of a sequence of fields. A format describes the 
relationship between the fieids of a message that are written/read by a 
program and the fields of the message that are received/transmitted by 
a terminal. 


Input formatting causes a message in the terminal message buffer to be 
moved» field by field» to the program message buffer. Output fornat- 
ting moves fields from the program message buffer to the terminal 
message buffer. When a field is rnoved» whether by input or output for- 
matting» it is moved under the control of an <iterm phras2>» the 
terminal message-buffer pointer and the program message-buffer potnter. 


An <item phrase> consists of a field type» a field length and an 
optional fieid detamiter. The field type defines which characters are 
valid in a field and controts its justification and filt.j The field 
length determines the number of characters in the field.j The field 
delimiters» if presents» designates the character which ends a fieid. 

The Terminal message-buffer Pointer (PT) refers to a particular characm 
ter position tin the terminat message buffere Likewise» the Program 
message"buffer Pointer CPP) refers to a particular character position 
in the program message buffer. 


Pointers PT and PP both begin pointing at the first character 

Cposition 1) in their respective aessages-e- As the editing phrases of a 
format are applied to data fietds» the data is moved from one message 
buffer to the other» and the pointers are updated. Unless sp2cifically 
instructed to do otherwises the pointers are updated by moving to the 
right by the number of characters moved. 


Example: 


Assume that the message “ABC 123" was received from a terminal and 
it was determined that the format (A3eI4) was to be applied. The 
Situation would initiatly appear as depicted in figure 3-9» with 
the message placed in the terminal message buffer» and the 

program message buffer cleared and the pointers initialized. 

The A3 <item phrase> controls the move of the farst three aipha- 
numeric characters as depicted in figure 3°10. As zan be seen»s 
"“ABC”™ ts placed into the program message buffer» and the pointers 
are moved three positions to the right. 
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PT sy 


Terminal Message Buffer Program Message Buffer 


Figure 3-9. Inittal Contents of Terminal 
and Program Message Buffers 


PT PP 


Terminal Message Buffer Program Message Buffer 


Figure 3°10. Contents of Terminal/Message 
Buffers After Move Caused 
by A3 <item phrase> 


Thens the I4& <item phrase> causes * 123" to be moved. During 
output» integer fields are right justified with zeroes filled and/ 
or blanks converted to zeroes. This "0123" is placed tnto the 
program message buffer. Figure 3-11 shows the final sttuation. At 
this point» the program message buffer is sent to Ene appropriate 


Application Prograa. 


A higher degree of formatting flexibility may be achieved by moving the 
pointers without moving text. The Terminal message-buff2r Pointer CPT) 
may be advanced without affecting the Program message~buf fer pointer 
CPC) by using a <skip field> Ci.e.» the X <editing phrase>)> but only 
PT may be advanced. PP may be moved in either direction without 
affecting PT by using a <tocation specifier>. 
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PT PP 
ABC 123 ABC0O123 
Terminal Message Buffer Program Message Buffer 


Figure 3-11. Contents of Terminal/Message 
Buffers After Move Caused 
by I4 <item phrase> 


Figures 3°12 thru 3-18 illustrate 
CAZ22I4eAlsX1ivaseAl) to the output 
and the <location speci fier>. 


Terminal Messag> Buffer 


the effect of applying the forsats 
message "WXYZ" using the <skip field> 


Program Message Buffer 


Figure 3-12. Contents of Inttialized 
Buffers 
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PT PP 
Terminal Message Buffer Program Message Buffer 


Figure 3713. Buffer/Pointer Update 
After Applying 
Specification A2 


PT Pp 


Terminal Message Buffer Program Message Buffer 


Figure 3°14. Buffer/Potnter Update 
After Applying 
Specification @4& 
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PT PP 
a ——— 


Terminal Message Buffer Program Message Buffer 


Figure 3715. Buffer/Pointer Update 
After Applying 
Specification Al 


| PT PP 
Terminal Message Buffer Program Message Buffer 
Figure 3715. Buffer/Pointer Update 


After Applying 
Specification Xi 
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a PP 
Terminal Message Buffer Program Message Buffer 


Figure 3-17. Buffer/Pointer Update 
After Apptying 
Specification 23 


eat PP 


Terminal Message Buffer Program Message Buffer 


Fagure 3718. Buffer/Pointer Updates After 
Applying Specification Ail 
and Sending the Terminat 
Message Buffer Contents 
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RECALL PROGRAM STATEMENT. 
Syntax: 


RECALLPROGRAM = <tdentifter>./ 
<empt y> 


<RECALL PROGRAM statement> 35 


Semantics: 


The <RECALL PROGRAM statement> specifies which program is to be 
designated as the Recali Prograae. The Recatt Program is used to 
recall both audited input and output messages. See section 8 for 
further explanation of: the Recall Program. GEMCOS supplies a 
Recalt Program caitled MCSRECALL on the release tapee Identifier 
must be 10 characters or Less in length. By defaults» there ts no 
Recatl Program. 


Examples: 
RECALLPROGRAM = MCSRECALL. 
RECALLPROGRAM = RECALLPROG. 
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CONTROL STATIONS STATEMENT. 
Syntax: 


<CONTROLSTATIONS statement> 33= CONTROLSTATIONS = 
<station identifier>. / <eupty> 


Semantics: 


The <CONTROLSTATIONS statement> allows one station to be designated 
as a Control station. Priviteged Network Control Commands say 

only be entered at the systea consoles the card reader or the Con- 
trol station. Errors monitored by the MCS are reported to the 
Control station if one is specified (Cotherwise the systenrm conssle 
is used). A <CONTROLSTATIONS statement> cannot occur in a 
regenerate MCSTCL run if ait did not occur in the GENERATE run. If 
the <CONTROLSTATIONS statement> occurs in the GENERATE runs its 
value may be changed in a REGENERATE run. fhe <station identi fier> 
must appear as a <station name> tn the <STATION section>. By 
defaults» no Control station is specified and no supporting Logic 


generated. 

Examples: 
CONTROLSTATIONS = TD8OOA. 
CONTROLSTATIONS = MANAGER. 
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DEFINITION SECTION. 


Syntax: 


<DEFINITION section> :3:= 
BEGIN 
<ACCESS CONTROL staterent> 
<PROGRAM section> 
<STATION section> 
<DEVICE section> 
<MESS CODE sect tion> 
END. 


Semantics: 


In the <DEFINITION section>»s the user defines access keys Cuser 
IDs)» programs and stations as well as their interretationships. 
If the user requires MCS functions not supported by GEMCOS»s UPL 
source code statements can be merged into a GEMCOS HCS by inctud- 
ing a <MESS CODE section> in the <DEFINITION section>. 


LS 
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cont 


ACCESS CONTROL STATEMENT. 
Syntax: 


<ACCESS CONTROL statement> ::= ACCESSCONTROL ; 
<association list> / <empty> 


<association Llist> s3= <assoctation> / 
<association tist> <association> 


<association> ss= ACCESSKEY <access code> = 
<item list>. 


<access code> s3:= <identifier> 

<item List> 23= <item> / <ijites> » <item List> / 
ALL 

<item> 33= <trancode> / <program name> 


Semantics: 


The <ACCESS CONTROL statement> aliows for the specification of 
access codese An access code is required as part of the sign-on 
command syntax (*SGN access code) and identifies the user signing on 
to the MCS. An access code identifier is an atphanumeric identifier 
up to six characters in lengthe Associated with eath access code is 
an <item tist> consisting of transaction codes (trancodes) and/or 
<program names> which that particutar user is authorized to use. 
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When a message is received from a stations the MCS searches for a 
transaction code in the messagee If soe the MCS determines if the 
access code used to sign-on at that station is authorized to use that 
trancode. If the access code is authorized» the message is routed to 
the appropriate programs otherwise» an error is returned to the station 
If a trancode couid not be found in the messager the MCS verifies that 
the access code ts authorized to use the program currently attached to 
the statione If so» the message is routeds if not» an error is reporte 


NOTE 
If the value of sign-on for a station is 
FALSE» access controt is not in affect 
at that station. No messages entered at 
such a station are rejected due to 
access control restrictions. 


Each trancode encountered in the <ACCESS CONTROL statement> aust 
appear in a <TRANCODE statement> of the <PROGRAM sezstion>. Like- 
Wise» each <program name> must appear in a <prograa define> of the 
<PROGRAM sectton>.j If a signed-on user ts to have unrestricted 

use of all the defined transaction codes and programs» the key word 
ALL may be usedej If ALL 3s used» it must be the only <item> in 

the <item list>. 


Example: 


ACCESSCONTROL : 
ACCESSKEY ABCD 
ACCESSKEY AB1234 
ACCESSKEY AB5678 


ALL. 
INQ» XYZ. 


ont ff 


PROGRAM SECTION. 


Syntax: 
<PROGRAM 


<program 


<program 


<program 
<program 
<program 


<PROGRAM 


<PROGRAM 


section> 23> 
define list> s3= 
define> 22> 
name> 2 ee 


classificatiton> 33= 


description> c= 


STATEMENT List> 33= 


statement> 3S 


PROGRAM Section 


<PROGRAM DEFINE List> 


PROGRAM DEFINE> 7 
<program define List> 
<program define> 


PROGRAM <prograa name> 
<program classification> ; 
<program description> 


<identifier> 


ASSIGNMENT / UTILITY 7/7 USER 7 
<ermpty> 


<PROGRAM STATEMENT List> 


<PROGRAM statement> / 
<PROGRAM STATEMENT tLast> 
<PROGRAM statement> 


<INTERFACE statement> / 
<TRANCODE statenent> / 

<PROGRAM TITLE statement> / 
<RESIDENCE statement> / 

<COMMON SIZE statement> / 
<EXECUTE statement> / 

<RECOVERY staterment> / 

<DATABASE NAME statement> / 
<AUDIT TRANSACTIONS statement> / 
<AUDIT ASSIGNMENT statement> / 
<AUDITY OUTPUT statement> / 
<RESTART PROGRAM statement> / 
<MAXCOPIES statement> / 

<OPEN MESSAGE statement> / 
<ATTACH MESSAGE statement> / 
<DETACH MESSAGE statemant> / 
<CONVERSATIONSIZE statement> / 
<MAXASSIGNERS statement> / 
<APSOOSTATUS statement> / 
<TRANSACTION CODE POSITION statement> 
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Semantics: 


The library of on-line programs is defined in the <PROGRAM section>. 
Ait programs that open a remote file which ts to be approved by 

the GEMCOS MCS must appear in the <PROGRAM section>. If a program 
attenapts to open a remote file consisting of at teast one station 

in the GEMCOS MCS remote file Cidentifted by the <QUEUE NAME 
Statement> of the <GLOBAL secttion>)» and if the program does not 
appear in the <PROGRAM sectton>» the MCS does not aitow the file 

to open. 


The <PROGRAM section> is composed of a <program define lList>. 
Each <program define> specifies a <program name>s a <program 
classification>» and a <program statement lList>. 


The <program nare> is any alphanumeric identifier. If there ts an 
<ACCESS CONTROL statement>» <program name> may appear in its 
<item fist> to altow certain <access codes> to use the programe 


The <program classification> specifies to the MCS how this program 
can be executed as well as how messages are to be routed to it 
once it is runninge As of the 3.0 GEMCUS release» there are three 
<program ctassifications>: ASSIGNMENT» UTILITY and USER. By 
default» <program classification> 1s ASSIGNMENT. 


ASSIGNMENT PROGRAMS. 

An Assignment Program may only be executed from the supervisory console» 
a card reader or the Control station. An attempt to exezute an Assign- 

ment Program from any other than the Controi station by means of the EX 

Network Control Command results tn an operator error. 


After being executed» an Assignment Program eventually opens a renaote 
file tn order to gain control of a list of stations in the network. A 
GEMCOS MCS grants control of a particular station to an Asstgnment Pro- 
gram if the MCS controls the stations and if no other Assignm2nt or 
Utility Program controls the statione The MCS controls a station if 
that station appears in the remote file opened by the GEMCOS MCS Crefer 
to stations controlted by a GEMCOS MCS in section 2). When an Assign- 
ment Program opens a remote files» the MCS checks each station defined 
to be in the program remote file. If the MCS determines that tt cannot 
grant control of any of these stations» the FILE OPEN is denied. 
Otherwise» the MCS approves the fite open request for the stations tin 
the List for which it is able to grant controt.j Once control of a sta- 
tion is given to an Assignment Programs all messages entered from 

that station that do not contain a trancode of a User Program are 
routed to the Assignment Program Cassuming access control is not 
violated). 


PROGRAM Section 


cont 


An Assignment Prograam retains control of its stations until it resolves 
to close its remote file. If a HAP Network Control Command is entered 
from the Control stations the supervisory console or a card readers the 
MCS places an End-of-fFile character into the queue of tha Assignaent 
Programs which prompts it to close its remote file and go to End-of-Job. 
When an Assignment Program ctoses its remote files» the stations are no 
longer considered busy and can be attached to another Assignm2nt or 
Utility Program. 


Thus» the GEMCOS MCS handles file opening and message routing for an 
Assignment Program in much the same way that a Network Controller does 
when no MCS is presente. Howevers GEMCOS also provides an Assignment 
Program with additional functtons such as a Commonrarea headers trancode 
indicies» access controls audit» recovery» and formatting. 


UTILITY PROGRAMS. 

A Utility Program may only be executed from a station in the network. 
An attempt to use the EX Network Control Command to execute a Utility 
Program from the supervisory console or a card reader is denied. A 
station may not "EX" a Utility Program if that station 18s already 
controlled by an Assignment Program or another Utility Program since 
the station would be considered busy. 


Upon receipt of an EX network control command from the stations the MCS 
determines» tn the order listed» the status of the foltowting as they 
pertain to the utility program: 


ae Program is runntinge 


be. Number of stattons attached to the program exceeds the 
Limit assigned. 


ce Number of program copies exceeds the Limit assigned. 


If the program ts not runnings the MCS initiates the program with the 
ZIP EXECUTE command. Afterwards the initiated program opens a duamy 
file. Afterwards the MCS attaches the requesting station. (CFor further 
information about dummy fites» refer to Burroughs B 1700 Systams 

Network Definition Language Reference Manuals fore number 1073715.) 


If the program is runnings the MCS checks whether the nuaber of sta- 
tions attached to this program exceeds the maximum asstgnment Limits if 
it does nots» the MCS dynamicatly attaches the station to the remote 
file of the program. However» if the number of stations attached to 
the program does exceed the Limit» the MCS then proceeds to check 
whether the number of program copies exceeds the timit established. If 
it does not» the MCS initiates a copy of the program and attaches the 
station to it. However» if the program copy Limit ts exceeded» the MCS 
displays an error message. 
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Once the attachment occurss the utility program controls the station. 
Ail messages entered froma that station which do not contain a trancode 
or aouser program are routed to the utility program. 


When the user is finished with a programs the HAP network control 
command is entered. This prompts the MCS to detach the station from 
the remote file of the utility program. The station is available and 
can be attached to another Assignnent or Utility Program. iIf only one 
station was attached to the program copys the MCS places an End-of-File 
character tn the Utility Program queue (for that copy only). The char- 
acter prompts the program to close the remote file and proceed to 
End~of~Job. 


GEMCOS handles a Utility Program tin much the same manner as the B 1700 
iliustrative MCS handles a program taat opens aremote file. However>s 
GEMCOS also provides a Utility Program with additional functions such 
as a Common-area header» trancode indicies» access controls audit» 
recovery» and formatting. 


USER PROGRAMS. 

A User Programs Like an Assignment Programs may only be executed froa 
the supervisory consoles a card reader or the Control station. An 
attempt to execute a User Program fron any station tin the network 
other than the Control station by means of the EX Network Control 
Command is denied. <A User Progran must use an interface of 
PARTICIPATION. 


After being executed» a User Program should open a remote file for 
stations it can service. The MCS approves the REMOTE FILE OPEN as 

long as the stations in the remote file are controiled by GEMCOS (those 
stations not in the remote file of the MCS being deleted from the 
remote file of the User Program). 


NOTE 
The MCS does not check to see if another 
on-line program controts the stations» 
since a User Program does not control 
stations. 


Unlike an Assignment Program or Utility Program» a User Program receives 
a message entered from a station in its remote file only if the message 
has a trancodee.e At a given point in time» a station may be attached to 
as many User Programs as necessary since the MCS ts able to switch 
messages entered at the station based on a trancode found in the message 
(a station may only be attached to one Assignment or Utility Program at 
a time and ail messages without a trancode go to that program). A 
statton may be simultaneously attached to an Assignment or Utility 
Programs even though it may still be attached to User Programs. 


PROGRAM Section 


cont 


A User Program must have at ieast one <TRANCODE statement> in its 
<PROGRAM statement List>s otherwise», the program cannot receive any 
messages. 


If several copies of a particular User Program are executed» the MCS 
distributes the message Load evenly among them. This feature can 
increase system throughput since itnputs/outputs CI/0s) can be 
overlapped. 


A User Program continues to service the stations in its remote fite 
until it closes its remote file. If a HAP Network Control Command is 
entered for this programs the MCS places an End~of-File character in 
the User Program queues prompting 1t to go to End-of~Job. 


Examples: 


PROGRAM A ASSIGNMENT: 
TITLE = PACKA/PAYROLL/. 
TRANCODE = UPDATE. 
COMMONSIZE = 60. 


PROGRAM B UTILITY: 
TITLE = EDIT/IT. 
COMMONSIZE = 75. 
RESIDENCE = CORE. 


PROGRAM C USER: 
TITLE = FIXIT. 
TRANCODE OLDC8s1). 
TRANCODE NEWC9»1). 
RESIDENCE = DISK. 


Hon 
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INTERFACE STATEMENT. 
Syntax: 


<INTERFACE statement> 3°:= INTERFACE = <program interface>. / 
<eapty> 


<program inter face> :3= NONPARTICIPATION / PARTICIPATION / MCS 
Semantics: 


The <INTERFACE statement> deterrgines the path smessages follow as 
they flow between a particular drogram and the stations in its 
remote file. It also deterrgines the relationship between the 
GEMCOS MCS and the program. Three interfaces are avaitlables 
NONPARTICIPATION» PARTICIPATION and MCS. The NONPARTICIPATION and 
PARTICIPATION interfaces say only be used by application progrags» 
programs which open a remote file without headers. The MCS inter- 
face may only be used by MCS programs» programs whish op2n a 
remote file with headers. By defauits» interface is PARTICIPATIIN. 


NONPARTICIPATION.j A NONPARTICIPATION interface is an efficient but 
static method for a program to cormunicate with the stations in 

its remote file. Figure 3-19 depicts the flow of messages tn a 
NONPARTICIPATION interface. 


Stations in 


Remote file 

of programs RSN2 Program 
e 
: GEMCOS MCS 


RSNX 


RSN signifies the Relative Station Number, 


Figure 3-19. NONPARTICIPATION Interface 
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With NONPARTICIPATION interface all messages Cexcept those beginning 
with a signal character) that are entered from all stations in the 
application program remote file go to the prograrmg.e. The program can 
write messages to any of its stations. A construct known as a reaote 
key allows the program to determine the source and length of an input 
and to specify the destination and tength of an output. 


Messages written by the program or entered from a station beginning 
with a signal character are sent to the MCS.j GENCOS Network Control 
Commands reach the MCS by means of thts stgnat character when a 
NONPARTICIPATION tnterface is chosen. 


Messagesre beginning with two signal characters» that are entered froa a 
Station are processed by the MCS tn the following manner: 


ae If a trancode is found in the message» the trans action is 
routed to the program specified by the trancode provided the 
program 1s running or dectared as ONDEMAND.j Output sessages 
from the program are routed back to the statton. This ailouws 
a user at a stations that ts attached to a non~participating 
programs to perforr trancode routing to other programs in the 
network. 


be. If the message (starting from the third character position only) 
contains a aessage~ID» it is considered to be a foras request» 
and the blank form ts sent back to the station. This feature 
is only avaitable in the advanced and total versions of GEMCIS. 


ce If the message contains neither a valid trancode nor message- 
ID» it ts routed to the program to which the station is 
attached. The first two bytes Cor two signal characters) are 
not returned with the message. 


The NONPARTICIPATION interface is efficient since a typizsal transaction 
passes through only one program» the User Program Cin addition to the 
Network Controller). This interface is static since a station can 

only be in one opened Cinput) remote file at a time and therefore has 
access to only one program. In additions the MCS does not have access to 
the normal flow of messages and is unable to provide audit» formatting» 
access control» and its other functions. 


When interface 1s NONPARTICIPATIONs> the program classifi:ation cannat 
be USER and there cannot be any transaction codes. The Common-area 
header wiit not be on messages received by the programs and the program 
must not provide them on outpute Thus» COMMONSIZE cannot be sete 
ATTACHMESSAGE» DETACHMESSAGE and OPENMESSAGE cannot be TRUE. Users at 
Stations in the remote fite of a Nonparticipation Program can neither 
use transaction~based routing nor initiate screen requests white the 
Nonparticipation Program is running. Even if station has been 
assigned a SCREENSIZE» screen wraparound cannot take plaze while the 
station is under control of a Nonparticipation Programe. Audit» queue 
restoration and formatting are not possible Ceven though these options 
can be specified in the <GLOBAL section> and can be used by Participa- 
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tion Programs attached to other stations in the network while 
Nonparticipation Programs are running). 


If stations can be dedacated to a particular program while th2 program 
is running and the program does not require access controls audit» 
queue restorations formatting or screen wraparounds it 13 advantageous 
to use the Nonpartictpation interface. 


PARTICIPATION. When PARTICIPATION is specified as the prograa inter- 
faces all messages entered at stations pass through the HCS before 
being sent to programs» and allt messages written by the program pass 
through the MCS before betng transmitted to stations. The MCS ts satd 
to be “participating™ in the message traffic flowing between the pro- 
gram and the stations of the program remote fite. Figure 3-17 depicts 
the flow of messages in a PARTICIPATION interface. 


Stations in 


Remote file | 
of Programs RSN2 GEMCOS MCS Program 


RSN signifies the Relative Station Number. 


Figure 3720. PARTICIPATION Interface 
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The PARTICIPATION interface is siightly tess efficient in teras of 
throughputs» since a typical transaction passes through three programs: 
the MCS (Cduring tnput)» the User Program» and the MCS again (during 
output). The slight decrease in efficiency is more than offset by the 
full complement of centralized functions provided by the MCS message. 
It can provide a full array of centralized functtons Cinstluding audit» 
recovery» formattings screen wraparounds access controls and 

various forss of routing). 


Programs which use the PARTICIPATION interface receive and must provide 
the Common-area header. This headers in addition to tits other func- 
tions» altows the program and MCS to communicate the message text 
Length and the source/destination station to each other. 


MCS. When a program is defined as using an MCS interface» the flow of 
messages is simgiltar to a NONPARTICIPATION interface. Ail messages 
Cexcept those beginning with the signal character) entered from each 
Station in the MCS program remote file go to the program. The MCS pro- 
gram can write to any station in its remote file. Figure 3-21 depicts 
the flow of messages in an MCS tnterface. 


RSN1 


Stations in 
Remote file 
of Programs RSN2 


Subordinate 
MCS 
Program 


GEMCOS 
Supervisory 
RSNx MCS 


RSN signifies the Relative Station Number. 


Figure 3-21. MCS Interface 
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Two areas in which the MCS tnterface differs frorm the nonparticipation 
interface are as follows; 


ae A program using an MCS interface must open its remote file 
with headers» thereby identifying ttself as an MCS to GEMCOS 
and the Network Controtier. 


b. The program must provide and expect a Network Controtier- 
defined 5O-byte header proceeding ali data messagese With 
this header» the program may access tallies and toggles and 
may perform functions such as output message switching» 
communication with the Network Controllers remote file 
managements system interrogations and system control. (The 
Network Controltler/MNessage Controt System interface is 
defined in Burroughs B 1700 Systems Network Definition 
Language Reference Manual» form 1073715.) 


When a program using the MCS interface opens its remote files GEMCOS 
assumes the status of a supervisory MCS while the program ts considered 
a subordinate MCS3. The supervisory MCS must be entered into the aix 
before any of the subordinate MCS programs. 


A program using the MCS interface can be either a Utility Prograrm or an 
Assignment Programe In brief» stations can dynamically attach to and 
detach from a Utility Program via the EX and HAP Network Control Coa- 
mands» while an Assignment -Program controls a fixed set of stations and 
can only be initiated from the Control stations» the supervisory 
printer or a card reader. 
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Messages entered at stations in a remote file opened by a subordinate 
MCS Cwhich do not begin with the GEMCOS signal character) go directly 
to the subordinate MCS and are not seen by GEMCDS. As a results» an MCS 
program temporarily suspends GEMCOS MCS functions Cexcept certain 
Network Control Commands) at the stations in its remote file. While 
stations are in the remote file of an MCS programs they  :annot use 
GEMCOS trancodess screen wraparounds audits recovery or formatting. 
Messages beginning with the GEMCOS signat character go to the GEMCOS 
supervisory MCS so that» even while a station is attached to a subordi- 
nate MCS» GEMCOS network control commands can be entered. 


NOTE 
Network Control Comaands affecting the 
attributes of stattons tn the remote 
file of an MCS program cannot be acted 
upon. The subordinate MCS 1s responsible 
for the attributes of the stattons it 
controls. 


The B 1800/B 1700 MCS/Network Controller interface altows subordinate 
MCS programs to change data communication attributes of associated 
stations. Howevers tf a station attribute is changed by a subordinate 
MCS» the change is effective onty while the subordinate MCS controis 
the station. As soon as either the subordinate MCS closes its renote 
file or the station detaches itself» GEMCOS returns the station to tts 
ortginal status. 


Examples: 
INTERFACE = NONPARTICIPATION. 
INTERFACE = PARTICIPATION. 
INTERFACE = MCS. 
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TRANCODE STATEMENT. 


Syntax: 


<TRANCODE statement> <2:= TRANCODE = <trancode list>./ 
<emoty> 


<trancode> <trancode indiceas>/ 
<trancode lList>» 
<trancode> <trancode indices> 


<trancode list> 


Semantics: 


The <TRANCODE statement> 1s used to define trancodes and to asso- 
ciate them with programs. A trancode identifier is any string up 
to ten characters in length. A program of any classification which 
uses an interface of PARTICIPATION may have associated trancodes. 
However» only trancodes associated with User Programs cause trans” 
action-based routing to occure A trancode defined in a <TRANCODE 
Statement> may occur in the <ACCESS CONTROL statement> to restrict 
its use to a specific List of <access keys>. 


The <module-function indicies> may optionalty be assoctated with 
each trancode.e. fhe <module-functtion indicies> consist of two 
<integer> values. Each <integer> may be a value from 0 to 63. 

If a trancode has <module-function indicies>» they are placed into 
the Commoncrarea header of messages itn which that trancode is 
presente The receiving program can use the <module~ function 
indicies> in a UPL CASE statement or a COBOL GO TO DEPENDING ON 
in order to branch to the code which will process that trancode. 
This eliminates the need for the application program to determine 
which trancode has just been received. If a trancode has no 
<module~function indicies> or if there is no trancode in a 
message», zeroes are placed into the <module-function indicies> 
field of the Common-area header. 

A User Program must have at least one <TRANCODE statement> in its 
<PROGRAM statement List>s otherwise» the program never receives 
any messages.- The <TRANCODE statement> is optional in the 
<PROGRAM STATEMENT tist> of Assignment and Utility ?rograms. 


NOTE 
If input formatting is to take places a 
message must have a trancode regardless 
of the classification of the destination 
prograa»s so that the MCS is able to 
determine which forsgat is to be applied. 
The trancode ts considered as one of the 
fietds of a formatted message. 


Examples: 


TRANCODE = INQ (8s 10)» UPDATE (55 3). 
TRANCODE = FIX (18» 1). 
TRANCODE = HELP. 
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PROGRAM TITLE STATEMENT. 
Syntaxs 


<PROGRAM TITLE statement> 72:= TITLE = <file-ID>./<enpty> 


Semantics: 


The <PROGRAM TITLE statement> identifies the object-code file name 
of a program. The <file-ID> is a 8B 1700 file tdenti fier and is 
used in the EXs HAP» RPS and RPC Network Control Commands to refer 
to the program.j The <PROGRAM TITLE statement> is optionat.j If it 
is omitted» the program titte defaults to the first 10 characters 
of <program name>. 


Examples: 
TITLE = PACKI/X/Y.~ 
TITLE = PGM1. 
TITLE = A/B/. 
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RESIDENCE STATEMENT. 


Syntax: 


il 


<RESIDENCE statement> *3= RESIDENCE 
<empty> 
<runstime residence> ::= DISK ¢ CORE 


<run=time residenca>. / 


Semantics: 


The <RESIDENCE statement> allows the user to specify where the 
program is to reside when not processing messages. The value of 
RESIDENCE may be CORE or DISK. A CORE Resident Program gives 
faster response but increases the memory requirements of the data 
communication system. The <RESIDENCE statement> is optional and 
defautts to CORE. 


Examples: 
RESIDENCE = CORE. 
RESIDENCE = DISK. 
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COMMON SIZE STATEMENT. 
Syntax: 

<COMMON SIZE statement> :3:= COMMONSIZE = <tnteger>. / <eapty> 
Semantics: 


The <COMMON SIZE statement> ailows the user to specify the tength 
of the header preceding the text of messages exchanged b2tween the 
MCS and application programs using the PARTICIPATION interface. 
<Integer> must be a value from 60 to 200. Sytes 1 through 60 are 
reserved for GEMCOS-defined fields. Bytes 61 through 200 can De 
reserved for user-defined fields. User-written code must be 
merged into the MCS 1f it is to access» set» or modify bytes 61 
through <integer>. The <COMMON SIZE statement> is optional. By 
default» COMMONSIZE defauits to 60 (no room reserved for user” 
defined fields). 


Programs uSing either the NONPARTICIPATION or MCS interface cannot 
receive a Common~areas and thus COMMONSIZE cannot be2 set. 


Examples: 
COMMONSIZE = 60. 
COMMONSIZE = 200. 
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EXECUTE STATEMENT. 


Syntax: 


ee 
6s 


<EXECUTE statement> EXECUTE = <execute option tist>. 7<empty> 


it 


<execute tist> / 
<execute list>» <execute option List> 


<execute option List> 33 


<execute List> ONDEMAND 7 BOJ / MANUAL 


Semantics: 


The <EXECUTE statement> allows the user to reduce interv2antion by 
the Console or Control Station oderator durtag prograa fire up. 
Three options are available> ONDEMAND»s BOJ» and MANUAL.~ ONDEMAND 
and MANUAL may not appear togetner in the same <EXECUTE statement>. 
The default for this statement is MANUAL. 


ONDEMAND. 

This option may only be dectared for User Programs. Norrally 

when an operator enters a message containing a tranzode for a 
program that is not runnings GEMCOS MCS displays an error message 
and the operator must wait until the program is exesuted through 
the Console or a Control Statton. However» when ONDEMAND its 
selected» GEMCDS MCS 71P-executes the prograa if it is not running 
when a trancode message is received for it. The first m2ssage 
received for the program causes the execute. 


ONDEMAND functions are internat and not visible to the operator. 
This feature enables the operator to enter messages without tnter- 
ruption. fhe messages are stored tin a *tank file". When GEMCOS 
MCS receives a FILE OPEN for the programs atl “"tank2d" massages 
for that program are sent to it in the same order as originally 
received by the GEMCOS MCS. The tank file is closed when it 
contains no more messagese 
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BOJ. 

The BOJ (Beginning-Of-Job) option may be declared for assignreent 
or user programs. When the GEMCOS MCS ts executed» it auto- 
matically executes all BOJ programs. 


NOTE 
It is advisable to be selective when 
declaring programs BOJ so the mix is not 
filled wath unnecessary jobs. 


MANUAL. 

MANUAL may be deciared for Utility» Assignment and User Programs. 
If a program dectared MANUAL is not runnings it must be executed 
with the EX command. Utility Programs can only be declared as 


MANUAL. 
Examples: 

EXECUTE = MANUAL» BOJ. 

EXECUTE = ONDEMAND. 
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RECOVERY STATEMENT. 
Syntax: 
<RECOVERY statement> ::= RECOVERY = <recovery tlist>. / <2mpty> 


<recovery list> 2:= SYNCHRONIZED / DATABASE / QUEUVERESTORATION 
NONE 
Semantics: 


The <RECOVERY statement> declares what type of recovery rech- 

anism (Cif any) this program undergoes after a system or progranm 
failure. Synchronized and data base recovery are for prograas that 
are part of a data basee Queuerrestorattion recovery is for pro- 
grams that are not logically associated with any other programs. 
The default for this statement 1s NONE] See section 9 for a 
detailed explanation of the recovery mechanism. 
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DATA BASE NAME STATEMENT. 


Syntax: 
<DATABASE NAME statement> ::= DATABASENAME = <database name List>. 
/ <empty> 
<database name lList> ’3= <database tdentifier> / 


<database identifier> ~» 
<database name list> 


Semantics: 


The <DATABASE NAME statement> associates a program with a data 

base. If recovery for a program is synchronized or data base» 

this statement must be present and specify the name of the 

data base that the program belongs tos otherwise» it ts not re- 
quired. If this statement is required but not givens a syntax 

error occurs. 


If the program is a Restart Program CRESTART PROGRAM = TRUE)» then 
more than one data base identifier may be specified providing that 
the Restart Program services more than one data basa. If the pro- 
gram is not a Restart Prograa»s only one data base identifier say 

be specified. <A data base identifier is an identifier that contains 
between 1 and i7 characters. 


Examples: 
DATABASENAME = MCSTESTDB. 
DATABASENAME = LIVEDBs TESTDB. 
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AUDIT TRANSACTIONS STATEMENT. 
Syntax: 


<AUDIT TRANSACTIONS statement> 
23= AUDITTRANSACTIONS = <trancode list>. / 
<empty> 


<trancode tlist> 33= <trancode> / <trancode> » 
<trancode iist> / ALL 


Semantics: 


The <AUDIT TRANSACTIONS statement> specifies which previously 
defined trancodes are to be audited by the MCS.j Only trans~ 
actions that cause the data base to be updated should be audited» 
since ali audited messages are reprocessed during recovery. If 
ALL 1s selected» no tndtviduat trancodes may be specified and allt 
trancodes for this program are audited. If recovery is required 
for this programs then either this statement or the <AUDIT ASSIGN-~ 
MENT statement> or both must be specified. By default» the MCS 
does not audit by trancode for any programe 


Examples: 
AUDITTRANSACTIONS = UPD. 
AUDITTRANSACTIONS = PAY» DEOL» DEO2»> ODFO4. 
AUDITTRANSACTIONS = ALL. 
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AUDIT ASSIGNMENT STATEMENT. 
Syntax: 


<AUDIT ASSIGNMENT statement> ::= AUDITASSIGNMENT = <togical value>. 
/ <empty> 


Semantics: 


The <AUDIT ASSIGNMENT statement> directs the MCS to audit or not 

to audit messages that do not have atrancode. Programs dectared 

as User Programs may not use this statement since all messages for 
that class of prograaw necessarily contain a trancode. User Programs 
that require recovery sust use the <AUDIT TRANSACTIONS staterent>. 
Programs of any other class that require recovery must use this 
Statement or the <AUDIT TRANSACTIONS statement> or both. By de- 
faults» the MCS does not audit by assignment. 


Examples: 
AUDITASSIGNMENT = TRUE. 
AUDITASSIGNMENT = FALSE. Z FOR DOCUMENTATION ONLY 
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AUDIT 


Synta 


Seman 


Examo 


OUTPUT STATEMENT. 
x3 
<AUDIT QUIPUT statement> ::= AUDITOUTPUT = <logical valua>. / 
<eapty> 
tics: 


The <AUDIT OUTPUT statement> directs the MCS to audit ail out- 
put messages from the prograa to the station. This statement 
must be set to TRUE for programs that use synchronized recovery, 
Otherwise» a warning is issued and the statement is automatically 
set to TRUE. For the MCS to audit output» a program must audit 
either by asstgnment or by transaction. Except for synchronized 
recovery» AUDITOUTPUT defaults to FALSE. 


less 
AUDITOUTPUT = TRUE. 
AUDITOUTPUT = FALSE. 
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RESTART PROGRAM STATEMENT. 
Syntax: 


<RESTART PROGRAM statement> *3= RESTARTPROGRAM = <togical value>. 
4 <empty> 


Semantics: 


The <RESTART PROGRAM statement> specifies whether or not this pro- 
gram 1s to be a Restart Program (see section 9 for a detailed ex- 

planation of a Restart Program and its functions). If this state- 
ment 1s set to TRUE» then the fotlowing must also be done: 


ae Recovery must be set to either synchronized or data base. 


be A <DATABASE NAME statement> must be supplied. More than 
one data base name is altowed if this Restart Prograr 
services more than one data base» and each data base uses 
the same type of recovery Csynchronized or data base). 


Each data base must have exactly one Restart Program declared» put 
a Restart Program can service multiple data bases. By default» 
RESTARTPROGRAM is set to FALSE. 


Examples: 
RESTARTPROGRAM = TRUE. 
RESTARTPROGRAM = FALSE. 
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MAXIMUM COPIES STATEMENT. 
Syntax: 

<MAXCOPIES statement> *3= MAXCOPIES = <integer>. / <empty> 
Semantics: 


The <MAXCOPIES statement> is used to specify the number of copies 

of this program that can be running Chave a remote file open) at 

any one time. For Assignment Programss the onty allowable vatue ts 
one. Yhe sum of MAXCOPIES for att programs determines how sany 
programs can be running in the MCS concurrently. An increase in 

the value assigned to MAXCOPIES during regeneration may consequently 
require generating and coapiting so that the MCS has a Larger value 
stack. The vatue of MAXCOPIES is safely lowered during regeneration. 
MAXCOPIES ts set to one by default. 


NOTE 
MAXCOPIES reptaces MAXRUNNING» a global 
option. MAXRUNNING should no Longer be 
usede 


Examples: 


MAXCOPIES = 
MAXCOPIES = 2. 
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OPEN MESSAGE STATEMENT. 
Syntax: 


<OPEN MESSAGE statement> °2= OPENMESSAGE = <lLogical value>. / 
<eapty> 


Semantics: 


When OPENMESSAGE is set TRUEs the program receivess as the first 
message in its remote file» information from GEMCOS tisting the 
Logical Station nuabers of the stattons which comprise the program 
remote file. The OPENMESSAGE consists of a Common-area header with 
an MCS“TYPE 6» LSN set to the nuaber of stations in the prograas 
remote file» and TEXTSIZE set to LSN *3. The text is set to a 

List of 3-byte Logicat Station Numbers. The OPENMESSAGE is not 
audited. 


If the interface is set to MCS» the Comaonmarea header its preceded 
by a B 1800/B 1700 MCS/Network Controller interface MCS to MCS 
DATA MESSAGE header with the MESSAGE TYPE FIELD set to 80. A 
program with an interface of NONPARTICIPATION cannot request the 
OPENMESSAGE. By defaults» OPENMESSAGE is FALSE. 


Examples 


OPENMESSAGE = TRUE. 
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ATTACH MESSAGE STATEMENT. 


Syntax: 


<ATTACH MESSAGE statement> °3= ATTACHMESSAGE = <logical vatlue>. / 
<empt y> 


Semantics: 


When ATTACHMESSAGE ts set TRUE» the program receives a message in 
its remote file giving the Logical Station number of a station 
Which just attached itself to the program (by means of the *EX 
Network Control Command). fhe first station to attach itself does 
not generate an ATTACHMESSAGE. The station can be obtained froa 
the OPENMESSAGE.} The ATTACHMESSAGE consists of a Common~area 
header with an MCSTYPE 2» an LSN set to the Logical Station number 
of the attaching stations SEQND set to the next audit sequence 
number» and TEXTSIZE set to 0000. No message text is sente 


If INTERFACE ts set to MCS» the Commonmarea header is preceded by 
a B 1800/78 1700 MCS Network Controller interface MCS DATA MESSAGE 
header with the Message Type field set to 80. A program with an 
interface of NONPARTICIPATION cannot request ATTACHMESSAGES. By 
defaults» ATTACHMESSAGE is FALSE. 


Example: 
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ATTACHMESSAGE = TRUE. 
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DETACH MESSAGE STATEMENT. 
Syntax: 


<DETACH MESSAGE statement> *:= DETACHMESSAGE = <logical value>. / 
<empt y> 


Semantics: 


When DETACHMESSAGE ts set TRUE» the program receives a message in 
its remote file giving the Logicat Station number of the station 
which has just detached itself from the program Cby means of the 
HAP Network Control Command). The Last station to detach itself 
does not generate a DETACHMESSAGE sitnce the program ts inforasaed 

of the fact Cit receives an End-of-File condition on its renote 
file). The DETACHMESSAGE conststs of a Commonrarea header with an 
MCSTYPE of 4» an LSN set to the Logical Station number of the 
detaching stations SEQNO set to the next audit sequence nuasber>» 
and TEXTSIZE set to 0000. No message text is set. 


If INTERFACE is set to MCS» the Common-area header is preceded by a 
B 1800/8 1700 MCS/Network Controller interface» MCS DATA MESSAGE 
HEADER with the Message Type field set to 80. A program with an 


interface of NONPARTICIPATIOGN cannot request DETACHMESSAGES. By 
default» DETACHMESSAGE its FALSE. 


Example: 


DETACHMESSAGE = TRUE. 
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CONVERSATIONSIZE STATEMENT. 
Syntax: 


<CONVERSATIONSIZE statement> 3:3= CONVERSATIONSIZE = <integer>. 
4 <eampty> 


Semantics: 


The <CONVERSATIONSIZE stateaent> is used to establish the size of 
the conversation area for a program. The size is specified in 
bytese The MCS cannot generate conversational capasilities with= 
out this statement in the TCL. Anytime this statement is increased 
to a value greater than any previously declared CONVERSATIONSIZE>s 
the TCL must be regenerated and recompiled. 


Examples: 
CONVERSATIONSIZE = 30. 
CONVERSATIONSIZE = 45- 
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MAXASSIGNERS STATEMENT. 


Syntax: 


<MAXASSIGNERS statement> 2:= MAXASSIGNERS = <integer>. 
/ <empty>. 


Semantics: 


The <MAXASSIGNERS statement> is used for utility programs only. 
This statement is used to specify the maximua number of stations 
that can be attached to a program concurrentty.j The maximus 
value cannot be greater than the number of stations allowed by 
GEMCOS. 8y default» atl attachments are applied to one prograa. 


Examples: 


MAXASSIGNERS = 5. 
MAXASSIGNERS = 
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TRANSACTION CODE POSITION STATEMENT. 
Syntax: 


<TRANCODE POSITION statement> *3= TRANCODE POSITION = <integer>. 
<empty> 


Semantics: 
The <TRANCODE POSITION statesent> allows the user to specify 
where trancodes are found tn messages from this programe. The 


position specified in <integer> represents the number of char- 
acters after the common area header. 


Examples: 


TRANCODEPOSITION = 6. 
TRANCODEPOSITION = 
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AP3OOSTATUS STATEMENT. 
Syntax: 


<AP3OOSTATUS Statement> ::= AP300STATUS = <logical value>. 
/ <empty> 


Semantics: 


The <AP300STATUS statement> indicates whether the four~byte 
AP300STATUS message from the AP300 is forwarded to the attached 
application program. The status of the AP300 ts reported to the 
control station or the systea SPO when the four-byt2 status is 
received. The default value is false. 

false. 


Example: 
AP30O0OSTATUS = True. 
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STATION SECTION. 


Syntax: 
<STATION section> ss 
<station define tist> 235 
<station define> ~ee 
<station name> 2s: 
<station description> -3= 
<STATION statement List> 23= 
<STATION statement> 22> 


Semantics: 


<station define tlist> 


<station define> / 
<station define list> 
<station define> 


STATION <station name>: 
<station description> 


<NDL station identifiear> 
<STATION statenent List> 


<STATION staterent> / 
<STATION statement tis t> 
<STATION statesent> / 
<ampty> 


<SIGNON statenent> / 

<SCREEN SIZE statement> / 
<TRANCODE POSITION statement> / 
<VALID ACCESS KEYS statement> / 
<TRANSACTION MODE statement> / 
<CONTINUOUS LOG ON statement> / 
<CONVERSATIONAL statenent> / 
<TRANCODE statement> / 

<TYPE statement> 


The <STATION section> must be present to define various attributes 
of stations which the MCS is to servicee CA GEMCOS MCS opens a 
remote file whose name is given in the <QUEUE NAME statement>.) 

In the FAMILY statement of the FILE SECTION of the user*s NDL 
sources this remote file was assigned a station identifier List. 
These are the stations which the MCS services and which sust 

be defined in the Transaction Control Language <STATION section>. 
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The <STATION section> its composed of a <station define List>. 

ach <station define> describes one statione, The <station name> 
must be the station identifier used to refer to that station in 
NDL. The <STATION statement list> is optional. One of the 
<station names> may appear itn the <CONTROL STATIONS statement> of 
the <GLOBAL section>. 


Example_: 


STATION TO800A: 
SIGNON = TRUE. 
SCREENSIZE = 1024. 
TRANCODEPOSITION = 5. 
VALIDACCESSKEYS = ABCD» XXYY» 84080. 
STATION TDS8O0B: 
SCREENSIZE = 1920. 
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SIGN-ON STATEMENT. 
Syntax: 

<SIGNON st atement> 32:= SIGNON = <togical value>. / <empty> 
Semantics: 


The <SIGNON statement> indicates whether a user must sign on at 
this station prior to entering messagese If SIGNON is TRUE» the 
operator must sign on with one of the <access codes> Listed in the 
<VALID ACCESS KEYS statement>. If VALIDACCESSKEYS ts set to ALL» 
the operator must sign-on with one of the <access codes> iisted 

in the <ACCESS CONTROL staternent>. The <SIGNON statement> is 
optional and» if omitted» defaults to FALSE. 


Examples: 
SIGNON = TRUE. 
SIGNON = FALSE. 
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SCREEN SIZE STATEMENT. 


Syntax: 


<SCREEN SIZE statement> *:= SCREENSIZE = <integer>.j / <enpty> 


Semantics: 


The <SCREEN SIZE statement> defines the length of the targest ses- 
sage which may be received by this station. If the MCS deterasines 
that a message larger than <integer> characters is bound for the 
Stations the message is broken into several transmissions until 
the entire message 1s sente 


CAUTION 
If any <station define> has a <SCREEN 
SIZE statement> tin its CSTATION 
Statement List>» all <station defines> 
must have onee If the <SCREEN SIZE 
statement> ts not presents» no screen 
wraparound occurse 


The occurrence of a <SCREEN SIZE statement> causes the screen- 
wraparound code to be generated into the MCS code file. If no 
Station ts defined as having a SCREENSIZE fess than or equal to 
MAXTEXT SIZE» the <SCREENSIZE statement> should be avotded. The 
result is a more effictent MCS. 


Examples: 
SCREENSIZE = 1920. 
SCREENSIZE = 256. 


37111 


STATION Section 


cont 


TRANSACTION CODE POSITION STATEMENT. 
Syntax: 


<TRANCODE POSITION statement> :°:= TRANCODEPOSITION = 
<integer>. / <empt y> 


Semantics: 


The <TRANCODE POSITION statesnent> allows the user to specify where 


trancodes are to be found in messages received from this station. 
By default» TRANCODEPOSITION is 1. 


Examples: 
TRANCODEPOSITION = 5. 
TRANCODEPOSITION = 1. 
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VALID ACCESS KEYS STATEMENT. 
Syntax: 
<VALID ACCESS KEYS statement> 


23= VALIDACCESSKEYS = <access key List>. / 
<empty> 


<access code> / <access code> » 
<access key tlist> / ALL 


<access key lList> 


ee 
i 


<identifier> 


<access code> 
Semantics: 


A list of vatid access keys can be prepared to enforce access key 
validation at sign-on timew Each <access code> whith appears in a 
<VALID ACCESS KEYS statement> must have occurred tn the <ACCESS 
CONTROL statement>. ALL indicates that any <access code> can be 
used to sign on at this station. If the statement is omitted and 
SIGNON 1s TRUE» ALL is assumed.ej This statement has no meaning if 
SIGNON ts FALSE. 


Examples: 
VALIDACCESSKEYS = ALL. 
VALIDACCESSKEYS = 84080» 84090» ABCD. 
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TRANSACTION MODE STATEMENT. 


Syntax: 


<TRANSACTION MODE statement> 3:2= TRANSACTIONMODE = <lLogical value>. 
/ <empty> 


Semantics: 


The <TRANSACTION MODE statement> determines whether or not a 
station is allowed to transmit a new tnput transaction before 
receiving the response for the previous tnput transaction. If 
TRUE» the MCS returns the error response “BUSY” for any input from 
the station prior to the receipt and transmission by the MCS of the 
response to the current transaction for the station. Alsoe this 
Station can only send messages to programs that are declared to 

use synchronized recovery. TRANSACTIONMODE being TRUE ts tgnored 
if auditing is not present in the MCS. By defaults» TRANSACTIONMDDE 
Is set to FALSE. 


Examples: 
TRANSACTIONMODE = TRUE. 
TRANSACTIONMODE = FALSE. 
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CONTINUOUS LOG"ON STATEMENT. 


Syntax: 


<CONTINUOUS LOG ON statement> :3= CONTINUOUSLOGON = 
<logical vatue>. / <empty> 


Semantics: 


The <CONTINUOUS LOG ON stateaent> is used to determine whether 

the MCS should "remember®™ who was togged on to the station 
following a termination of the network Ceither normally or 
abnormaltly).j After the network is restarted» if CONTINUDUSLOGON 

is TRUE for a stations the user remains Logged one Otherwise» any 
users who were Logged on at the time of failure will be logged off. 
CONTINUOUSLOGON being set to TRUE ts ignored tf auditing ts not 
present in the MCS. By default» CONTINUOUSLOGON ts set to FALSE. 


Examples: 
CONTINUOUSLOGON = TRUE. 
CONTINUOUSLOGON = FALSE. 


37115 


STATION Section 


cont 


CONVERSATIONAL STATEMENT. 


Syntax: 


<CONVERSATIONAL statement> ::= CONVERSATIONAL = <logical vatue>. 
4 <empty> 


Semantics: 


The <CONVERSATIONAL statement> determines whether a station can 
participate tn a conversation. 8y default» the statement is set 


to TRUE. 

Examples: 
CONVERSATIONAL = TRUE. 
CONVERSATIONAL = FALSE. 
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TRANCODE STATEMENT. 


Syntax: 


<TRANCODE statement> ::= TRANCODE = <trancode tist>. / <empty> 
<trancode tist> ::= <trancode> / <trancode>»s<trancode lList> 


Semantics: 


The <TRANCODE statement> is used to deftne trancodes and to 
associate them with stations. A trancode identifier is any 
string up to ten characters in Length. A trancode defined in a 
<TRANCODE statement> may occur tn the <ACCESS CONTROL statement> 
to restrict its use to a specific list of <access keys>. 


By using these trancodes» messages from another station or prograr 
can be routed to this station. 


NOTE 
The <modulecfunction indicies> are not 
applied to trancodes. 


Exasples: 
TRANCODE = STATION» STATION2» HELLO. 
TRANCODE = HELP. 
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TYPE STATEMENT. 
Syntaxs 


<TYPE statement> 33= TYPE = <type tist>. / <empty> 
<type List> :3= AP300 / MT6500 / STANDARD 


Semantics: 


The <TYPE statement> is used to define the physical type of each 
Station. AP300 and MT600 are standard Burroughs terminal devices. 
(Refer to section 10 for further information about this statement.) 


Examples: 
TYPE = AP300. 
TYPE = ROUTEHEADER. 
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DEVICE SECTION. 


Syntax: 
<DEVICE section> s3s= <device define list> 
<device define List> s:= <device define> / 
<device define list> <device define> 
<device defitne> 23= device <device name> : 
<device description> 
<device name> ss= <identifier> 
<device description> ss= <DEVICE statement List> 


<DEVICE statement list> :2:= <DEVICE staterment> / 
<DEVICE statement tist> 
<DEVICE statement> 


<DEVICE statement> ss= <STATION List statement> / 
<INPUT FORMATS statement> / 
<OUTPUT FORMATS statema2 nt> 


Semantics: 


The <DEVICE section> is used to group stations by device class and 
to indicate which format is to be applied to a messagee The 
<DEVICE section> should be present if and only if the <FORMAT AND 
FUNCTION statement fist> is present in the <GLOBAL section>. The 
<DEVICE section> may never occur if the 8 1800/B 17)0 GEMCOS 
release being used 1S not an advanced version. 


Each <device define> consists of a <STATION LIST statement>» an 
<INPUT FORMATS statement> and an <OQOUTPUT FORMATS statement>.j The 
<device name> may be any identifier and is not referenced 
elsewhere in TCL. 
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In the following examples an input message from TD8J0A or TD800B 
with trancode INQ or UPDATE is formatted using format Xe A mes 
sage from TD700A» YTD7008 or TD700C with trancode INQ or UPDATE 
has format Y applied. 


Simitarly on output» if a program writes a message with the 
message ID field of the Comaon~area header set to "PAY" or "SHIP* 
Cleft justified with trailing blanks)» format X12 15s used when the 
message is bound for TD800A or FD8008. Format Yi2 is applied if 
the message is bound for a station in the device class TD/700 
CTD700A» TD7008 or TOH700C).j When the message"ID field of the 
Common-area header is set to “"RCV"™» X33 or Y33 is applied» again 
depending on the destination of the message. 


Finatty» when an operator transaits "PAY* or “SHIP” Cwithout lLead- 
ing or trailing blanks) from station TD800A or station TD800B» the 
operator is making a forms requeste Using format X12» a message 
is built up with all blank data fields CA» Bs I» J and 1). The 
message 3S sent to the requesting station. Format ¥12 %s used to 
create the blank-formatted screen if the forms requ2st for "PAY" 
or “SHIP™ came from TD700As» TD07008» or TO700C. If a "RCV" forms 
request is received» format X33 or Y33 is applied»s depending on 
the device classification of the requesting station. 


NOTE 
Formats X» X12» X33» Yeo Yi2 and Y33 must 
have been defined in the <FORMAT AND 
FUNCTION statement list>. 


Examples 


DEVICE TD800: 
STALIST = TD800A» TDBO0B. 
FORMATSINS 
X = INQ» UPDATE. 
FORMATSOUT : 
X12 = PAY» SHIP. 
X33 = RCV. 
DEVICE TD700: 
STALIST = TD700A» TDZO0Bs TD700C. 
FORMATSIN: 
Y = INQ» UPDATE. 
FORMATSOUT = 
Y12 = PAY» SHIP. 
Y33 = RCV. 
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STATION LIST STATEMENT. 
Syntax: 
<STATION LIST statement> ::= STALIST = <station name List>. 


<station name tlist> $2= <station name> / 
<station name tist>» <station name> 


<station name> s3s= <identifier> 

Semantics: 
The <STATIGN LIST statement> specifies the stations which are to 
be considered part of each device classe Each <station name> aust 
be defined in the <STATION section>» and each <station name> 


occurring in the <STATION section> should appear in exactly one 
<STATION LIST statement>. 


Exasples 
STALIST = TD820A» TDB20B»> T0820C. 
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INPUT FORMATS STATEMENT. 
Syntax: 
<INPUT FORMATS statement> %s= FORMATSINS <input format List>. 


<input format list> 23= <input format association> / 
<input format tist> 
<input format association> 


<input format association>::= <format-1D> = 
<trancode list> 


<forsat~ID> :3= <identifiter> 


<trancode tlist> 3s= <trancode> 
<trancode list>» 
<trancode list> 


<trancode> 23= <trancode identifier> 
Semantics: 


The <FORMATSIN statement> tndicates which format is to b2 applied 
to a particular message entered at a station of a particular 
device class before the message is forwarded to the appropriate 
programe. Only messages with a recognizable trancode are foraat- 
ted. Each <format~ID> must be defined in the <FORMAT AND 
FUNCTION statement List>» and each trancode aust be defined in 
the <PROGRAM section>. A trancode may only be assoziated with 
one <format-ID> per <FORMATSIN statement>. 


The MCS determines 1f an input message 1s to be formatted by 
attempting to recognize a trancode in the message texte When a 
trancode is founds the message is formatted only if the trancode 
was associated with a <format~ID> in the device class deterained 
by the station where the message originated. 


Examples 
FORMATSIN: 
MT1 = PAY1» PAY2. 
FaT2 = INVi. 
FMT3 = INV2» INV3. 
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OUTPUT FORMATS STATEMENT. 
Syntax: 
<OUTPUT FORMATS statement> ::= FORMATSOUT: <output format List>. 


<output format tlist> $3= <output format assotitiatton> / 
<output format list> 
<output format associtation> 


<output format association> 323= <format-ID> = <msg ID lList> 
<format~ID> s3= <identifier> 


<MSG"ID Llist> 23> <message-ID> / 
<msg7ID List> » <message-ID> 


<message-I)> :3= <identifier> 
Semantics: 


The <FORMATSOUT statement> indicates which format is to be applied 
to a particular message written by a program bound for a station 
of a particular device classe Only messages with a recognizable 
<message-ID> in the message"ID field of the Common-area header are 
formatted. Each <format~-ID> must be defined in the <FORMAT AND 
FUNCTION statement List>. <A <message-ID> may only be associated 
with one <format-ID> per <FORMATSOUT statement> and cannot exceed 
six characters in length. Station operators can enter a message 
consisting solely of a <message-ID> ands in doing soe make a foras 
requeste 


When the MCS receives a program message» the messag2e~ID field in 
the header is checked. If the fietd is filled» the contents cause 
the MCS to foramat the message according to the <format-ID> associ- 
ated with the <message~-ID> in the device classe The device class 
is determined by the station to which the message is sent. 


When the MCS recetves a message one to six characters in Length 
Without a recognizable trancode from a stations a check is sade 
to determine if the message consists of a <message~ID>.j If sop 
the operator entered a forms request. The MCS builds a message 
with blank data fieids using the <format~-ID> with which the 
<message-ID> was associated in the device class determined by the 
Station from which the forms request was received. 


Example: 
FORMATSOUT: 


FOR = PAY8»s PAY9. 
FMT1 = INV1. 
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MESS _ CODE SECTION. 


Syntax: 


<MESS CODE section> *2:= <static dectarations> 
<dynamic declarattions> 
<procedure define list> 


Semantics: 


The <MESS COOE section> enables the user to include UPL-mergeable 
external source statements to supplement or replace GEMCOS MCS 
functions. Mergeable external source statements ar2 for special- 
ized requirements which demand deviation from the standard GEMCDS 
logic. User-written MESS procedures can be merged into key ltoca-~ 
tions in the MCS source code file. 


NOTE 
Changes made to the <MESS CODE section> 
during a REGENERATE MCSTCL run do not 
affect the MCS source code file. 


The <MESS CODE section> consists of <static declarations>» 
<dynamic declarations> and a <procedure define lList>. The <MESS 
CODE section> is optional. 


Examples 


STATIC DECLARATIONS: 
DECLARE 
xX FIXED; 
ENDSOURCECODE. 
DYNAMIC DECLARATIONS: 
DECLARE DYNAMIC 
SPEC.STRING CHARACTER(Cx )> 
ENDSOURCECODE. 
PROCEDURE SETSIZES: 
PROCEDURE MESS.SET.SIZES>s 
z 
DECLARE 
ACCEPT.STRING CHARACTER(5)> 


DISPLAY "ENTER STRING SIZE» XXXXX"5 
ACCEPT ACCEPT.STRING=> 
X S= BINARYCACCEPT.STRING)> 
END MESS.SET.SIZES=» 
ENDSOURCECODE. 
PROCEDURE SETVALUES: 
PROCEDURE MESS.SET.VALUES> 


4 
SPECeSTRING s= * “5 
END MESS.SET.~VALUES> 
ENDSOURCECODE. 
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Syntax: 


€static deci aratitons> 


<static declarations card> 


<dectaration source cards> 


MESS CODE Section 


cont 


<static declarations card> 
<deciaration source :ards> 
<end card> / <empty> 
static declarations: 


<declaration source :ard> / 


<declaration source cards> 
<deciaration source tard> 


<UPL DECLARATION statement> / 
<UPL DEFINE staterent> / 
<UPL FILE statement> 


<dectlaration source card> 3: 


<end card> *3= ENDSOURCECODE. 


Semantics: 


In <static declarations> the user may make UPL global declarations 
Cexcept dynamic declarations)» global defines and file declarations. 
The TCL source cards containing UPL source statements must be 
surrounded by a TCL <static dectarations card> and a TCL <end card>. 
The <static dectlarations> are oadtional. 


If <static dectlarations> are present» the <NAME STACK ENTRIES 
statement> and <VALUE STACK BITS statement> of the <GLOBAL section> 
Should be set appropriately. 


Example: 
STATIC DECLARATIONS: 
DECLARE 
SECURITY-FILE.OPENED BITC1)3 
FILE 
SECURITY (LABEL = *"MCSSEC*>» 
DEVICE = DISK RANDOM> 
RECORDS = 80/1» 
BUFFERS = 1)3 
DEFINE 
F AS #FIXEDE>» 
Cc AS #CHARACTERE;> 
ENDSOURCECODE. 
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DYNAMIC DECLARATIONS. 
Syntax: 


<dynamic dectarations> ss= <dynamic declarations card> 
<dynamic declaration source cards> 
<end card> / <empty> 


<dynamic declaration card> 2:= dynamic declarations: 


<dynamic dectaration source cards> 

. 23= <dynamic declaration source card> / 
<dynamic dectaration source cards> 
<dynamic dectaration source card> 


<dynamic declaration source card> 
ss= <UPL DYNAMIC DECLARATION statement> 


<end card> 22:= ENDSOURCECODE. 


Semantics: 


In <dynamic declarations> the user may make UPL dynamic declarations. 
The TCL source cards containing UPL source statements must be sur- 
rounded by a TCL <dynamic declarations card> and a fTCl <and card>. 
The <dynamic declarations> are optional. 


If <dynamic declarations> are presents» the <NAME STACK ENTRIES 
Statement> and <VALUE STACK BITS statement> of the <GLOBAL section> 
should be set appropriately. 


Example: 


DYNAMIC DECLARATIONS: 
DECLARE DYNAMIC 
WORK.AREA CHARACTERCMSe«NPReMAXWTEXT.SIZE#250)3 
ENDSOURCECODE. 
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Syntax: 
<procedure define list> s3= <procedure 
<procedure 
<procedure 
<procedure define> s3= <procedure 


MESS CODE Section 


cont 


define> / 
define list> 
def ine> 


introduction card> 


<UPL PROCEDURE statenment> 
<end card> / <enpty> 


<procedure introduction card> 


= procedure <mess procedure-ID> ; 


<MESS procedure~ID> ss= AUDIT / CLOSEACTION 7 


CLOSEFILES 


f ERRORHANDLER 7 


MSGFROMPROGRAM / MAINTENANCE / 
MSGFROMSTATION / OPENACTION / 
HANDLERECALL / INITIATERESTORE 7/ 
RESTOREPROGRAM / SETSIZES / 


SETVALUES 


oe 
oe 


<end card> 


Semantics: 


= ENDSOURCECODE. 


The <procedure define list> contains user-coded UPL procedures» 
one per <procedure define>. Each <procedure define> begins with 
a TCL <procedure introduction card>» follows with the us2r's 
source statements and ends with a TCL <end card>. The <mess pro- 
cedure-ID> of the <procedure introduction card> specifies to TCL 
where the users code ts to be merged. fhe <procedure define 


last> 1s opttonat. 
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If <procedure define list> is presents the <NAME STACK ENTRIES 
Statement> and <VALUE STACK BITS statement> of the <GLOBAL sec= 
tion> should be set appropriately to reflect the space r2quired 
for variables declared within any of the user-writt2n procedurese 


A discussion of each of the MESS procedures 1s given tater in this 
section. 


Example: 


PROCEDURE MSGFROMSTATION: 
PROCEDURE ZIP.IF BITC1)> 
z 
IF MS.sMSG.TEXT.SIZE GIR 3 
THEN 
IF SUBSTROMS.MSGeTEXTs023) EQL *ZIP™ 
RETURN C1), 
END» 
RETURN (0)> 
END ZIP.IT> 
ENDSOURCECODE. 
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MESS_PROCEDURES»} 


This discussion explains when MESS procedures are calted» the parameters 
required to calt thems and the values they must return. For an expta- 
nation of how to include MESS proceduress refer to GENERAL DISCUSSION 
of TRANSACTION CONTROL LANGUAGE in this section. Alt MESS procedures 
are optional. 


Several considerations common to each MESS procedures are now discussede 


Care must be taken when writing MESS code to avoid duplizs ating identi- 
fiers already used in the MCS. For this reasons it is useful to know 
that ail MCS identifiers adhere to the following conventi ons: 


ae DEFINES begin with three characters: “MD." or *MS.". 
be. files begin with three characters: "MCS". 

ce Data names begin with three characters: “*S.". 

Ge Procedure names begin with four characters: "MCS... 
ee. DO~-group tabels begin with three characters: “ML.". 


MESS procedures have access not only to entities declared in <static 
dectaratitons>» <dynanic declarations>» and ltocaliy» but also to many 
data areas» files and procedures used by the standard MCS modules 
according to the scope rules of UPL. 


When programming MESS codes segmenting procedures must be followed. 
Some efficiency in memory altocation may be realized if MESS procedure 
segments are approximately 800 to 1200 bytes tn stzes the average size 
of standard MCS modules. 


If global or tocat variables are declared by the user in the <MESS CODE 
section>» the <NAME STACK ENTRIES statement> and <VALUE STACK BITS 
Statement> of the <GLOBAL section> shoutd be set appropriately. 

SET SIZES. 

This procedure is given control during the first phase of initiatiza- 


tion Logic tin the MCS. Its purpose is to specify sizes for any dynamic 
variables declared in the <dynamic dectarations>. 


Example: 
Assume that <static declarations> include: 
DECLARE MAX.SIZE FIXED; 
and that <dynamic dectlarations> inctude: 


DECLARE DYNAMIC USER-AREA CHARACTERCMAX.SI ZE)3 
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Then the SETSIZES routine must be provided. The <procedure define 
list> might include: 


PROCEDURE SETSIZES: 
PROCEDURE MY.SETSIZES.~ROUTINEs 
MAX.SIZE 3= 1003 
END MY-SETSIZES ROUTING, 
ENDSOURCECODE. 


The SETSIZES MESS procedure 1s called from MCS.INITIATE.~SIZES. 


2ET_VALUES- 

This procedure is given control during the second phase of tnitializa- 
tion logic in the MCS. The purpose ts to specify values for variables 
that were dectared tn the <static decilarations>. 


Examples: 
Suppose the <static declarations> include the fotlowing: 


DECLARE MAX.VALUES FIXED» 
USER.DATA CHARACTERCLO)> 


Consequently» the SETVALUES routine must be provided. The 
<procedure define ilist> can inctude the following: 


PROCEDURE SETVALUESS: 

PROCEDURE MY.SETVALUES.ROUTINE> 
MAX.~VALUES == 2003 
USER.-DATA == "SOMETHING"”> 

END MYeSETVALUES-ROUTINE> 

ENDSOURCECODE. 


The SETVALUES MESS procedure is calted from MCS.~INITIALIZE-TABLES. 
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MESSAGE FROM STATION. 

This procedure is called upon receipt of a message from a station. 

If MSGFROMSTATION is given controls it may assume that there is no 
data~communication error associated with the messages the MCS ts not 
being shutdowns the source station is signed on if sign-on ts required 
at that station» and the message does not begin with the signal char- 
acter. The Common-area header to be associated with thts message was 
built in MS-COMMON.AREA Cbut not yet attached to the message). If a 
trancode is presents it was recognized and noted tn MS.TRNeINDEX. The 
message was not yet formatted and could be a forms request Cadvanced 
version only). The message was not yet audited. 


MSGFROMSTATION must be a function procedure which returns a itrbit value 
specifying disposition of the message: 


ae A value 0 (zero) directs the MCS to continue processing the 
message as if there had been no MSGFROMSTATION procedure. 


be A vatue 1 signifies that the MSGFROMSTATION prozsedur2 has 
taken full responstbility of the message. The MCS 
discontinues processing this message. 


If a station 1s associated with or was attached to the remote file 

of a program that uses a NONPARTICIPATION or MCS interfazse» the GEMCDS 
MCS does not receive any messages from that statione Thause the MCS 
cannot pass controt to MSGFROMSTATION for such messages. 


This procedure can set fields in the USERAREA (MS.COMMDN. USER) of the 
Common-area header. It can perform specialized routings access controt 
or input formatting» and thus be used for data collection. 


MESSAGE FROM PROGRAM. 

This procedure is called when the MCS receives a message from an Appli- 
cation Prograa (the MCS does not receive messages from programs using the 
NONPARTICIPATION or MCS interface). The message was not formatted 
Cadvanced version) nor was 1t audited. The message may 3e a request 

for message restoration or may contain a signat character. 
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MSGFROMPROGRAM must be a function procedure which returns a in~bit value 
specifying the disposition of the message: 


ae A value 9 (zero) informs the MCS to continue processing 
the message as if there had not been a MSGFROMPROGRAM 
procedure. 


be A value 1 means that the message was completety processed. fhe 
MCS exits immediately to the main control procedure and does 
not process this message any more. 


This procedure can be used to interpret the USERAREA field 
CMS.-COMMON.USER) of the Common-area header. “4SGFROMPROGRAM can perfora 
specialized outout formatting. Nonstandard routing (eege» prograa-to-~ 
program message switching) can be performed using this procedure. 


MAINTENANCE. 

This procedure is given control when a message containing the signal 
character is received from a station or a program Cexcept for valid SGN 
messages). The MAINTENANCE procedure is cattled from the standard sain-~ 
tenance module (MCS.MAINT.CONTROLLER) if generated. The standard main-~ 
tenance module is generated if either CHANGEREQUESTS» DATADUMP> 
MESSAGEBROADCAST» MESSAGERECALL» PROGRAMBODJEDJ» STATUSRE? ORTS>» 
SYSTEMHAL Ts RESTORATION» or MONITORTRACE ts TRUE» or 1f an <ACCESS 
CONTROL statement> is present. When the standard maintenance module is 
not generated» the MAINTENANCE procedure is tnvoked by MCS.MSGeFROM.ASTATION 
or MCSeMSG.F ROM.USER~PROGRAM. 


The MAINTENANCE procedure sust be a function procedure which returas a 
im-bit value specifying the disposition of the message: 


ae A vatue 9 Czero) indicates that MAINTENANCE did not 
process the messagee If the standard maintenanze 
module 1S presents it attempts to scan for a standard 
command and process ite If the standard matntenance 
module ais not presents the input 1s ignored. 


be. A value t causes the MCS to consider the message completely 
processed whether or not the standard matntenanze module 
is presente 


MAINTENANCE must accept one input parameter: the number of the calling 
procedures (CFIXED). 


This procedure can be used to implement new Network Control Commands or 
change existing commands. 
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AUDIT. 

This orocedure can either supplement or replace the standard auditing 
logice It is catled after the standard audit procedure (if g2nerated) 
is executed. Any files needed by AUDIT must be dectared in the <GLOBAL 
section> of MESS code. 


AUDIT must accept two parameters: 
ae The number CFIXED) of the calling procedure. 


be An indicator (CHARACTER (€2)] which denotes the type of sessage 
being sent from the MCS: 


1) A value of 00 indicates the message is bound for a station. 
2) A value of O1 indicates the message is bound for a program. 


3) Other values denote special communications petwean the MCS and 
the Network Controller. 


ERROR HANDLER. 

The primary function of this procedure 1s to supplement the standard 
error handling module of the MCS. As a secondary function it may also 
save the contents of MS.-MSGeWORK.AREA in case of a data dump. For cer- 
tain system errors» a data dump is created. The standard error handling 
logic induces the dump by synthesizing an RDM Network Controt Comsand 

tn MS.MSGeWORK.AREA. The message that was stored in MSe4SGeWORK.AREA 
when the error was detected is therefore Lost» unless thea ERRORHANDLER 
procedure saves ite 


This routine must accept one parameter: the error message number 
CCHARACTERC2Z2)] which corresponds to the error detected. 


ERRORHANDLER must be a function procedure that returns a value (BIT (1)] 
which telts the MCS what to do with the error conditions 


ae A value 0 (zero) indicates that the error should be 
processed normally. 


b. A value of {1 indicates that the MCS is to exit the error 
handling module immediately. 


The ERRORHANDLER procedure is catled by MCS*PRINT.ERROR. 


CLOSE FILES. 

The CLOSEFILES procedure is given control during system shutdown CEOQJ). 
Its prisgary purpose is to close any files that may have deen opened in 
other MESS routinese- This ts cailed only by the MCS.EO0J procedure. It 
1s not called unless the generation parameter SYS“HALT is sete 
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HANDLE RECALL. 

The HANDLERECALL procedure is given controt during system shutdown 
CEQJ). At this time» the MCS recails all messages which have been 
routed to a station but are stilai awaiting transmission in the queues 
of the Network Controller. The HANOLERECALL procedure 1s invoked each 
time a message returns to the MCS. 


The HANDLERECALL procedure must be a function procedure which returns a 
vaiue (83ITC1)1] specifying disposition of the message: 


ae A value 0 (zero) causes the MCS to print the message 
on a line printer before discarding ite 


be A value 1 causes the MCS to discard the sessage 
without further processing. 


If this procedure is not orovided»s the MCS prints all recalled messages 
before discarding them. 


This procedure is cailed only by MCS.EO0J. It ts not cathed unless the 
generation parameter SYS"HALT is sete 


INITIATE RESTORE. 

This procedure is given control when an application program indicates to 
the MCS that it needs restoration (by sending a message which has the 
MCSTYPE field of the Common-area header set to 1)- It may either sup- 
plement or replace the module that performs restoration itnitializations 
depending on the <RESTORATION statement>. [ts purpose 1s to perform 

any initialization that may be necessary to prepare for restoration. 


This procedure is called only by MCS.~MSGeFROM.USER.PROGRAM. 


RESTORE PROGRAM. 

This procedure is intended to replace the standard MCS restoration 
logic. [t is called from the main processing Loop in MCS.MODULE. 
MANAGER. It is catlied once in each iteration of the loop as long as 
the flag MS»RESTORE.~PROGRAM has a value of 1.2 If it ts necessary to 
handte other network activity during restoration» MESS.~ROESTORE~PROGRAM 
must relinquish control (i.e. RETURN) occasionally so that the main 
processing loop can run through another cycle. 


37154 


MESS Procedures 


cont 


OPEN ACTION. 

This procedure ts intended to reptace or supplement the action taken by 
the MCS after a FILE OPEN STATION ATTACH is approved. Normattly» the 

MCS sends a “good day™ message to each station in the newly opened file 
ands if specified in TCL» a FILE OPEN notification is sent to the prograa. 


The OPENACTION procedure must be a function procedure which returns a 
value [BIT (1)]. 


ae A value 0 (zero) causes the MCS to send the “good day* 
messages and the open notification. 


be. A value 1 causes the MCS to skip the code which sends 
the “good day™ messages and the open notification. 


If the action taken by the OPENACTION procedure depends on whether it 

1s called through a FILE OPEN or through a STATION DETACH» the source 

of the call can be determined by checking the data field MS.MSGeHDR.TYPE. 
If the field contains 10» the OPENACTION procedure has been cailed 
through a FILE OPEN. If it contains any other values it has been 

calited through a STATION ATTACH. 


CLOSE ACTION. 

This procedure ts intended to supplement the MCS remote fite close or 
STATIONDETACH logic. It ts calied after the MCS performs the necessary 
Steps to verify that a program is no longer on-line. The CLOSEACTION 
procedure must be a function procedure which returns a value (BIT (1)]. 
However» the vatue of the return is of no consequence and 4s reserved 
for future use. One useful function of the CLOSEACTION procedure might 
be to construct and send a notification of the FILE CLOSE to the 
Stations involved. 


If the action taken by the CLOSEACTION procedure depends on whether it 
is calied through a remote FILE CLOSE or through a STATIONDETACHs the 
source of the call can be determined by checking the data field 

MS .MSGHDR.TYPE.] If this field contains 16» the CLOSEACTION proce- 
dure has been cailed through a FILE CLOSE. If tt contains any other 
value» tt has been catled through a STATIONDETACH. 
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COMMON-AREA_ HEADER. 
The Commonwarea header precedes ali messages sent to programs using the 
PARTICIPATION interfaces and 1t is required in front of ali m2ssages 

written by such programs. 
from 60 to 200 bytes by program as specified in the <COMMONSIZE 


statement>. 


The following is a detailed explanation of 


header: 
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The tayout of 


The Length of the Common-area headar can vary 


the Commonrarea header 1s as fotiows: 


01 COMMONAREA. 

05 MSGDESTINATION PICTURE 9€1). 
05 LSN PIC 9€3). 
05 PGMNBR REDEFINES LSN PIC 9€3). 
05 MISMSGTYPE PIC S$9(€1). 
05 SEQND PIC 9€6). 
05 NDLTIME PIC 9¢€7). 
05 TEXTSIZE PIC 9(€4). 
05 TERMTYPE PIC 9€2). 
05 MSGID PIC X(6). 
05 INDEX1 PIC 9(2). 
05 INDEX2 PIC 9(€2). 
05 ERROR PIC 9(€1). 
05 -FMTERR PIC 9€1). 
05 MCSTYPE PIC 9€2). 
95 INPUTADDR PIC 9(9). 
05 RETRYCOUNT PIC 9(€1). 
05 RECOVERYSTATUS PIC 9€1)- 
05 QJUTPUTADDR PIC 9(€9). 
05 CONVERSATIONSTATUS PIC 9{€1). 
05 CONVERSATIONBOJEDJ PIC 9(€1). 
05 USERAREA PIC XC ). 


each fietd in the Common-area 


MSGDESTINATION - This field can be filled in by the application 


program to indicate special routing. 


It is used primarily 


for program-to~program or program-to-station trancode routing. 
The GEMCOS system fills the field with the default value 


before sending it to the program. 
gram need not adjust the value unless special routing is required 


Thus» the aoplication pro- 


A tist of the values for this field and the default values» set 


by GEMCOS» follow. 
section 4.) 


0 - Send to 


default) 


Send to 
no default 


Route with 


Route with 


(For descriptions of these fields» refer to 


indicated station (final destination - no 


indicated program (final destination - 


) 
trancode (Cfinai destination - no default) 


trancode. Return to station (the GEMCOS 


System sets the value to zero). 


Common-area Header 


cont 


4 - Route with trancodes return to program C(GEMCDS sets 
default to 0) 


5 - Program can not send this value. It is set dy GEMCDOS 
to indicate that the message originates from a route 
header station. It should not be altered untess an 
intermediate tranrasaction is required. See section 10 
for explanation of routeheader stations. 


LSN Clogical Station Nuaber). For incoming messages or 
recovered incoming messagess this field contains the LSN 
of the originating station. Outgoing messages are sent 
to the station whose LSN is stored in this field. For 
attach notifications and detach notificationss this field 
contains the LSN of the station involved. For open noti- 
ficationss this fieid contains the number of stations in 
the approved FILE OPEN. 


PGMNSR Cprogram number) - This field contains the porograa 

number of the origtnating program in the event that the aessage 
must be routed back to the programe It redefines the LSN field» 
so that no LSN is present if a program number is speci fied. 
MSGDESTINATION wiil be 1. 


MISMSGTYPE Cmodular tersinai system message typ2) - This 
field is used to identify incoming and outgoing messages 
when the source or destination is an MYS terminati. Refer to 
section 10 (station types) for a detailed explanation of 
this field. 


SEQNO (Sequence Number). The MCS assigns a unique number 
to each message. That number ts passed to the application 
program in this fietd. 


NDLTIME. This is the time that the Network Controller sends 
the message to the MCS. 


TEXTSIZE. For incoming messages» this 1s the length in 
characters of the message text. It does not inzlude the 
length of the Common-area header. For open notifications it 
is set to the LSN field nultiplied by 3. When the application 
program writes a message» it must use the ACTUAL KEY of the 
remote file to specify the text size. In this tase» the size 
must include the size of the Common-area header. 

TERMTYPE (CTerminal Type). The MCS sets this field on 
incoming messages to a code which tdentifies the type of 

the originating device. Terminalctype codes are assigned 

in the Terminal section of NDL. 


MSGID (Message-ID). The MCS sets this field to blanks 

for incoming messagese If the program sets this fteid to 

a valid <message-ID> (refer to the <OUTPUT FORMATS statenent>)>» 
the MCS formats the message before transmitting it to a station. 
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cont 


If the program ieaves the field blank» the MCS does not format 
the message. 


INDEX1 (CModule-Function Index One). If an incosing message 
contains a valid trancode and that trancode has module function 
indicies defined in TCL» the MCS sets this field to the first 
index> otherwises this field is set to zero. 


INDEX2 (Module-Function Index Two). If an incoming message 
has module function indicies defined tn TCL» the MCS sets 
this field to the second indexs otherwises this field 

is set to zero. 


ERROR - If the MCS detects an error while routing (by trancode) 
a message from a program» a value is returned. Definitions 
fotiow for these values: 


0 - No error 

1 - Missing trancode (trancode routing was speci fied) 

2 - Requested program or station not available 

3 - Return station ID is invalid 

4 - Error tn routeheader Cprocessor to processor) message 


FMYERR (Format Error Indicator). If the MCS detects an 
error white formatting an incoming messages this field 
is set. Note that errors detected while formatting 

an outgoing message are reported to the Controt station. 
Refer to the discussion of formatting errors under 
<format dectaration> for an explanation of the values 
which can be found tn this field. 


MCSTYPE (Message Type). The message type fieid identifies the 
type of message being exchanged between the user application 
program and the MCS. fhe allowed values and their meanings ares 


Value 


15 


i7 


i8 


20 


21 


22 


Common area Header 


cont 


Meaning 


On inputs this is a message from a station. On outduts 
this is the tast (primary) message for the current 
transactione 


Not used on tnpute On outputs this ts a secondary 
message (i.2@es the program has additional responses to 
send for this transaction). 


On inputs» this is a station attach notification. Not 
used on output 


On input» this its a station detach notificattone Not 
used on outpute 


On input» this is a file open notification. Not used 
on output 


On inputs this message instructs the Restart Prograa 
to pass recovery information back to the MCS. Not 
used on output 


Not used on input. On output» this message is sent by 
the Restart Program to the MCS. It contains recovery 
information requested by the MCS. 


Not used on inpute On outputs this message is sent Dy 
the Restart Program to inform the MCS that an error 
was founde 


Not used on input. On output» this message is sent to 
the MCS to indicate that the user applt: ation progran 
needs recovery. 


On input» this message instructs the user application 
program to prepare for recovery. Not used on output 


Not used on inpute On outputs this message is sent by 
the user application program to inform the MCS that it 
is ready for recovery Cused in response to a type 21 
message only). 
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Value Meaning 


23 On input» this message is sent by the MCS to the user 
application program immediately after the remote file 
is opened. Its purpose is to pass information to the 
program that must be saved in the restart data set. 
Not used on output 


24 On input» this message is sent to the user application 
program instructing it to close its data base and pre- 
pare to terminate processing. Not used on output 


25 Not used on input. On outputs this message is seat by 
the user application program to inform the MCS that 
the program has successfuliy closed its data base and 
1S now ready to terminate processing. 


INPUTADDR CInput Audit Disk Address). This field contatnas the 
audit-file disk address of this transaction. If this field is 
zero» this transaction was not audited. 


RETRYCOQUNT CTransaction Retry Count). This field contains the 
number of times this transaction was subnitted to the user 


applicatton program. The value ts incremented Dy on2 whenever 
an input transaction causes a user application program to abort. 


RECOVERYSTATUS (CSystem Recovery Status). This field indicates 


the system status at the time this transaction was s2nte “The 
allowed values and meanings are: 


Vaiue Meaning 
0 The system 35 not in recovery mode. 


1 The system ts in recovery mode caused by a user appli- 
Cation program abort. 


2 The system is performing an archival re:overy. 


3 The system is in recovery mode caused by a Clear/Start 
or an abnormal termination of the MCS. 


Common area Header 


cont 


Value Meaning 


OUTPUTADDR COutput Audit Disk Address). This fieid contains 
the audit file disk address of the output message generated 
by the user application programe. This field is not used by 
the progran. 


CONVERSATIONSTATUS.j This faeld indicates whether the conver- 
sation path is clears a conversation 18S in progress» or an 
error occurred by the tast messages Descriptions follow far 
each value that is possible in this field: 


0 - Path is clear. There is no conversation in progress at 
the stations or the station 1s nonconversati onal. 


1 - Conversation in progresse The value of the 
CONVERSATIONBOJEOJ field indicates whether the station 
is communicating with a progran. 


2 7" Errore. Maximum number of conversations was exceeded. The 
Last message is neither audited nor delivereds but 
returnede 


3 - Error. Conversation is attempted with a nonconversational 
station. Message is returned. 


4 - Error. Conversation attempted with a conversing station. 
Message is returned. 


5 - Error. A nonconversationat program attempts to inittate a 
conversation. Message is returned to the program. 
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cont 


te CONVERSATIONBOJEDJ. This field indicates the b2ginning and 
the end of a conversation. The field is kept upsto-date 
through the messages fron the user. Descripttons folfow for 
each value that is possibte in the field: 


1) For messages to stations: 


0 - End of conversations or no conversations in progress. 
The MCS expects message text immediately after the 
common area header. 


1 - Conversation is beginning or continuing. Conversation 
text is located between the common area header and the 
message text. Conversation text ts stored tin the con=- 
versation area. If GEMCOS is auditing the partici- 
pating programs the conversation text ts audited as 
well. 


2) For messages from stattons: 


0 - Unoccupted. By returning this value» the station 
indicates it is open for conversation. 


1 - Occupied. This vatue verifies to the prograag that it 
is In conversation with the station. Conversation 
text follows the comnon area header. 


ue USERAREA. If COMMONSIZE is 60» the User-area field does 
not existe. If COMMONSIZE is greater than 60» the Length 
of the Userwarea field (n) is COMMONSIZE minus 50. User- 
written MESS procedures sust be written if this field 
is to contain significant information. 


As previously mentioned» the Comaon~area header is placed in front of 
the text of messages exchanged between the MCS and programs using the 
PARTICIPATION itnterfaces The Length of the text is determined by the 
TEXTSIZE field. For incoming messages and recovered incoming messagese 
the text is the data recetved from a terminal.j For open notifications» 
the text is a List of 3-character» Logical Station numbers.j No text is 
associated with attach notifications or detach notifications. For out= 
going messages» the Application Program sets the text to the data to be 
sent to a terminal. 


The attachs detach and/or open notifications can be requested by a 
program using the MCS tnterface. In this case» GEMCOS writes an MCS- 
TO-MCS data message with a message tyne-S0 (refer to Burroughs 8 1790 
Systems Network Definition Language Reference Manual» form 1073715). 

The text of this data message is a Common-area header. Therefores a 
subordinate MCS which expects attach» detach and/or open notifications 
must be able to handle an MCS-to-MCS data message from GEMCOS in 

addition to the MCS/Network Controller message types (refer to table 3-1). 
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Table 3-1 


Commonwarea Header Firetds 
Containing Valid Information 
by MCSTYPE 


Written by MCS 
MCSTYPE (#1) 


Written by User Program 
MCSTYPE (a2) (#3) 


Field 


2a 


6 21 23 


MSGDESTINATION 
LON 

PGMNBR 
MTSMSGTYPE 

SE QND 

NDOLTIME 
TEXTSIZE 
TERMTYPE 
MCSGID 

INDEX1 

INDEX2 

ERROR 

FMTERR 

MCSTYPE 
INPUTADDR 
RETRYCOUNT 
RECOVERYSTATUS 
OUTPUTADDR 
USERDATA 

TEXT 
CONVERSATIONS TATU: 
CONVERSATIONBOJEOJS 


Ke OK OK OR OK OOO OK OO OK OK OK OK 


c 


~ «Kx S 


SELLE LET IL TT ITE TET TET ETL OTTO ELIS 


1 An X denotes that the field is set by the MCS and contains valid infor- 
mations a U indicates that the field 3s set by the MCS only if 
procedures for this were specified by the user. 


2 A Y denotes that the H4CS requires the application porogram to provide 
valid information in the fietds a V denotes that the field is read by 
the MCS only if procedures were specified by the user. 


3 A W denotes that the MCS requires the application program to provide 


information in the field» provided the program employs queue 
restoration recovery. 
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MONITOR- 

To aid in monitorings each routine in the MCS is assigned a 3-digit 
number. The first of the three digits is a code indicating to which 
module the procedure belongs. The module number 0 (zero) is reserved 
for MESS procedures. fhe tast two digits identify the procedure. Num 
bers 90 thru 98 may be assigned to MESS procedures by the MESS 
programmer. 


Corresponding to the last two digits of the procedure number are 99 
monitor flagse A given procedure is monitored onty if the MCS was gen- 
erated with the MONITOR parameter set and the corresponding monitor 
flag has a value of 1. There are two ways to change the settings of 
monitor flags: 


ae When the MCS is running» by entering a CMF Cchange monitor 
flag) Network Control command. 


be. When the MCS is not runnings by running the TCL compiler 
With REGENERATE and setting MONITORTRACEON TRUE or FALSE. 


If a procedure 1s to be monittoreds it must contain at least one call on 
the monitor procedure. The monitor is invoked by a UPL statement of 
the form: 


MD-MONITOR(n1» sive nee $2)> 
The MD.-MONITOR parameters are as fottows: 


ae Parameter nl is the number of the procedure that 
called the current procedure. 


be. Parameter si ts a string of up to 30 characters 
specifying the name of the current procedure. 


Ce Parameter n2 is the number of the current procedure. 


de Parameter s2 is a string of up to 82 characters 
which contains any inforaation that may be useful 
for debugging Cusualty the names and contents of 
significant data items). 


Each time MD.MONITOR is invoked Cand the corresponding monitor flag 

as 1) these parameters are printed in order on one tine of thea sonitor 
Listings along with the sequence number of the Line which catled the 
MONITOR procedure. 


Monitor calis are ordinarily the first executable statemant of each 


routines howevers they can be placed anywhere that is usaful for 
debugging. 


57144 


NCC 


NETWORK CONTROL COMMANDS~ 

A Network Control Command (NCC) consists of a signal characters a 

short mnemonic command code» and in some cases» one or more parameters. 
Commands are free in forms with words separated by one or more spaces. 


Every Network Control Comgand generates some kind of response. There 
are three kinds of responses: 


ae Confirmation without data. This response is specified 
by the user through the CNCC OK RESPONSE statement). 


be Confirmation with data. For Network Control Commands 
which request that data be returned» the data itself 
serves as confirmation that the conmand was exesuted. 


Ce Rejectione If a command was not successfully executed» 
a message 18 returned giving the reason. 


In defining the syntax of Network Controi Commandss the following 
conventions are used: 


ae Alt undertined uppercrcase words are key words and are 
required when the functions of which they are a part 
are utilized. 


b. Upper-case words which are not underlined are optionat 
and may or may not appear in the message. 


Ce Lowercase words are generic terms which must b2 
supplied by the user. 


d.- When words or phrases are enclosed in brackets []» they 
may be ancluded or omitted at the user*s choice. Wh2n 
words or phrases are enclosed in braces » a choice of 
one of the entries must be made.w In both cases» a chotce 
1s tndacated by vertically stacking the possibilities. 
When brackets or braces enclose a portion of syntax» but 
only one possibility is showns the function of the brackets 
or braces 1s to delimit that portion of the syntax to 
which the following ellipsis applies. 


ee The ellipsis (2e+) represents the position at which 
repetition may occur. Repetitton is optional. The portion 
of syntax to be repeated 13s that which is enclosed within 
the Logically matching pair of brackets or bracas whose 
right-hand member tmmediately precedes the ellipsis. 


f.- The colon character (3) is required when it app2ars in the 


syntax» even though it is not underlined. The cotion must 
be preceded and followed by at least one space. 
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Je 


The 


asterisk (*) is used to denote the location of a 


Signal character. The actual character used tn place 
of the asterisk its detersrined by the <SIGNAL CHARACTER 
statement>. 


The 


term "station~specifier™ is to be replaced oy either 


of the following: 


1) 


2) 


The 
the 


1) 


2) 


The 
the 


1) 


2) 


The alphanumeric station identifier assigned to 
the station in the Station sectton of NDL. 


A number which specifies the position that the 
Station definition occuptes in the Station 
sectton of NDL.j (CThe first station defined is 13 
the second station defined is 2% and so on.) 

This number is also known as the Logical Station 
Number (LSN). 


term “program~specifier”™ is to be replaced dy either of 
followings: 


The alphanumeric program identifier assigned to the opro- 
gram in the Program section of TCL. If a Titte statement 
1S givens then this name should be used. 


A number which spectfies the position that the program 
definition o¢cupies in the Program section of TCL. (The 
first program defined is is the second program defined 15s 
2% and so one This ts tndependent of the number of copies 
of any progran.) 


term “data base~specifier™ 1s to be replaced by either of 
following: 


The atphanumeric data base identifier assigned to the data 
base in the DATABASENAME statement of the Program section 
of ICL. 


A number which specifies the position that this data 
base was presented in TCL. The first data base defined 
is 0% the second data base 18s 15 and so One 


SECURITY CONTROL COMMANDS. 
These commands can be used only if an <ACCESS CONTROL statement> 
appears tn the user source TCL. 


SIGN ON CSGN). The SGN command ts used to gain access to the system at 
a station which requires signing one 


Syntax: 

* SGN access~code 
Example: 

@ SGN ABCD 


In this example» the ABCD ts signed on if it is defined in the 
<ACCESS CONTROL statement> and is vatid for that station. 
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SIGN OFF CBYE).}j The BYE command disconnects a signed-on user froa a 
station. The user should sign off after completing the transaction to 
ensure that no unauthorized person is able to gain access to the system. 
BYE cannot be entered from a station which does not require signing one 
If the user ts attached to a Utility Program (via the EX command) at 

the time "*BYE*" as entered» an impiicit HAP of that Utility Program 

1S automatically done by the MCS. 


Syntax: 


* BYE 
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ENABLE USER CEUS). The EUS command ts used to mark an azcess code as 


enabled. The enabled user-ID» with the correct passwords 


used to sign-on. 
Syntax: 

* EUS access7"code 
Example: 

@ EUS ASscodD 


In this exanmpter» the user ABCD 


may 


Sign one 


can then be 
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DISABLE USER (DUS). The DUS command is used to prevent an access code 
from betng used for logging one 


Syntax: 

« 0US access~-code 
Example: 

a DUS ABCD 


In this example» the user ABCD is no longer able to sign-on until 
the access code is enabled again. 


37150 


NCC 
cont 


PROGRAM CONTROL COMMANDS. 
These commands can be used only if the PROGRAMBOJEOJ is TRUE. 


EXECUTE PROGRAM CEX). The EX comnand is used to start Assignsents User 
or Utility Programs» or to attach a station to a Utility Programa which 
is atready running. Confirmation of this command merely indicates that 
MCS communicated ZIP-execute to the MCPs it does not guarantee that 

the program actually started. 


Syntax: 
*EX program-name execute~optionclist 
execute-option-tist °3:= execute~option / execute-option List» 
execute~option / 


empty 


>= LOCK / {€charge-number}) / user-password 


execute"option 
chargernumber *2s= <integer> 


user-password ::= US <usercode> “/* / 
US = <usercode> “*/* 


Semantics: 


The execute options are described in detail in the 8B 1800/B 1700 
Systems Software Operation Guides form number 10687351. If the 
user-password option was entered during a normal rune it wilt not 
be present in the ZIP execute statements used for recovery. 


NOTE 
The GEMCOS system does not check for 
valid usercodes. If the system is 
unsuccessful perforrning ZIP execute with 
the user codes the user must initiate 
the program by using the SPO. 


EX PROG/A 

EX PROG/A 12345 

PROG/A US AB/CD 

EX PROG/A LOCK US = AB/CD 

EX PROG/A US AB/CD 12345 LOCK 


2 @ @ & 
mr 
x< 
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HALT APPLICATION PROGRAM CHAP). The HAP command is used to cause an 
End-of-File condition on the remote file that an Assignment or User 
Program has open. In the case of Utility Programs» the station at 
which the HAP command was entered is detached from the program. When 
the last station detaches itself» an End-of-File condition is sent to 
the Utility Program. Program-name is optional only for utatlity 
programse If this command is entered during a conversation at a 
stations the conversation is autoaaticatly terminateds and th2 
conversation area is cleared. 


Syntaxs 
* HAP Cprogram-nanme] 
Example: 


a HAP PROG/A 
a HAP 
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MCS CONTROL COMMANDS. 
There are two MCS Control commands: AOK and HLT. 


AUDIT OK CAOK).j The AOK command is used in response to a message on 
the Control station or on the console printer of the form: 


FILE MISSING - MCSAUDIT/AUDITXXX 
It informs the MCS that the requested audit file is available on disk. 
This command can be entered only at the console printer through an 
ACCEPT. 
Syntax: 


* AQK 
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HALT SYSTEM CHLT). The HLT command brings the data communications system 
to a stop. This command can be used only if SYSTEMHALT is TRUE. 


fe HLT KILL 


Semantics: 


If KILL 1s not specified» the system comes to an orderly stop» and 
untransmitted messages are recatled.j If KILL is specifiads the 
system comes to an abrupt stops and messages may be loste 
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MESSAGE CONTROL COMMANDS. 
There are two MCS controt commands: BRC and PQ. 


BROADCAST CBRC). The BRC command its used to send a message to other 
stations in the network. It is available only if MESSAG: BROADCAST is 
TRUE. 


Syntax: 


Sstation=speci fier 
* BRC eee = messagetext 


2P0 
Semantics: 


More than one “statton-speciftier™ may be entered» in which case 
the message is sent to each station. If no station-specifier is 
entered» the message 35 sent to all stations in the network. If 
SPO 3s entered» the message is sent to the console printer. 


Examples: 


a BRC =: GOOD MORNING 
@ BRC 3 TD4 = WHAT*S HAPPENING? 
@ BRC SPO = PLEASE LOAD PROGRAM BLACK/JACK 
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POP QUEVE (PQ). The PQ command is used to recall messages from the 
output queue of a statione This command can only be used if 
MESSAGERECALL is TRUE. 


Syntaxs 
PRINT 
* PQ Stationwspecifier~1 ALL 
SEND station-specifier~2 


Semantics: 


If ALL is not entereds only the otdest message is racaliled. If 
ALL is entered»s then all messages in the queue are recalled itn 
orders with the oldest one first. If neither PRINT nor SEND is 
specified» recalled messages are discarded. PRINT sauses recalled 
messages to be printed on a system printer. SEND causes recatled 
messages to be sent to the tndicated statton. 


Example 1: 
aPpas 


For this example one message from the queue for station 5 is 
retrieved and discarded. 


Exampie 2: 
a PQ 3 ALL PRINT 


For this example all messages for station 3 are recatited and 
printed. 


Example 33 
a PQ TDi SEND TD2 


For this example» one message for TDi is sent to TD2 instead. 
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REPORT COMMANDS. 

With the exception of RDM» which is controlied by the DAFADUMP state- 
ment DATA“DUMP» the existence of these commands is controtled by the 
<STATUS REPORTS statement>. 


When examining error statistics it should be kept in mind that: 
ae Counters start at zero each time the MCS is exersuted. 


be The MCS increments a counter by the retry Limit when the Net- 
work Controller reports an error to the MCS» but the Network 
Controller reports an error only when the retry Limit is 
exceeded. Thus» the number of errors reported in the res~ 
ponse to the Network Control Command may be slightly less than 
the number that actualty occurred. 


REPORT DATA DUMP CRDM).- The RDM command allows access to the contents 
of MCS data fields. 


Syntax: 
* RDM PRINT 

Semantics: 
When PRINT is specified» the report is sent to a system printer 
and the contents of MCS tables are included. When PRINT 1s not 
entered» only nontable infornation is included. Other r2port 


commands are available for displaying table information at a 
remote station. 
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REPORT FILE STATUS CRFS).j The RFS command returns the following 
information about a remote file: 


ae File name. 

b. Queue number of the remote file. 

ce Name of the program which opened the remote file. 
Syntax: 

* REFS (file-name] 


Semantics: 


If *file-name*™ is not entered» the status of atl remote fites is 
returned. 


Example: 
a RFS REMOTL 
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REPORT PROGRAM STATUS CRPS). The RPS command returns the following 
information about a program: 


ae Name of the progran. 
be Whether or not the program is running. 
Ce Program classification. 
Syntax: 
* RPS Cprogram-specifier ] 


Semantics: 


If "“program=specifier™ is not entereds the status of ait 
programs 1s reported. 


Example: 


a RPS PROG/A 
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REPORT PROGRAM COUNTERS CRPC). The RPC command returns the following 
information about a program: 


ae The number of the programe. (See definition of program specifier). 
be Number of messages sent to the program. 


ce Number of messages received from the program. 
de The job number of the programs if it is running. 


Syntax: 
* RPC Cprogram-speci fier ] 
Semantics: 
If “program~specifier™ is not entered» the status of all 
programs is reported. If there is more than one copy of a program 


CMAXCOPIES > 1)» statistics are given for all copies of the pram 
gram including copy number. 


Examples: 


a RPC MY/PROG 
a RPC 2 
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REPORT STATION COUNTERS CRSC). The RSC command returns the following 
statistics about a 


ae 
be 
Ce 
de 
Ce 


Syntax: 


Number 
Nuaber 
Number 
Number 
Number 


of 
o f 
o f 
o f 
o f 


station: 


messages sent. 

messages received. 

data communications errorse 

Network Control Commands affecting the station. 
changes made. 


* RSC Cstation-speci fier } 


Semantics: 


If no 


all stations. 


Example: 


aRSC TD1 


"station~specifier™ is provided» statistics are reported for 
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cont 


REPORT STATION STATUS CRSS).j The RSS command reports the fotilowing 
about a station: 


ae Whether the station ts ready» enabled» signed on or attached. 
be. Usage Cinput» outputs or both). 
ce Which program the station is attached to» if any. 
Syntax: 
* RSS Cstation~specifierl] 


Semantics: 


If no "station~soecitfier™ is provided» status is reported for ait 
stations. 


Exauptle: 


a R35 TD1 
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CHANGE COMMANDS. 
The existence of these commands ts controtled by the <CHANGE REQUESTS 
Statement> and the <MONITOR TRACE statement>. 


CHANGE MONITOR FLAG CCMF). The CMF command is used to enable or disable 
monitoring of procedures in the MCS. 


Syntax: 

* CMF Cflag-number ]...:? 
N 

Semantics: 
A “flag-number™ is the Last two digits of a procedure nusber. 
More than one flag number may be entered. If no flag number is 
entereds ail monitor flags are changed.j N Cnormal) sets the 
monitor fiag(s) to 0 Czero)s D Cdiagnostic) sets the monitor 
flag(s) to l. 

Example 1: 
@aCMF 13 : D 


Procedures which have “13" as the last two digits wilt be monitored. 


No procedures are monitored. 
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CHANGE STATION ADORESS CCSA). The CSA command ts used to give the Net- 
work Controller a new Logical address for a station. 


Syntax: 
* CSA station~speci fier address 
Q 
Semantics: 


Codes I or O tndicate whether the new address applies on input or 
outpute 


Example: 
a2CSA 501A 


Station 5 will have an output address of "1A". 
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CHANGE STATION DIAGNOSTIC (CCSD). The CSD command is used to tnform the 
Network Controller whether or not to use normat dtagnostic request 
Logic Cas defined in NDL) for a station. 


Syntax: 


* CSD station-specifier 


D 


Semantics: 


The code N selects normal request logics D setects dtagnostic 
logic. 
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CHANGE STATION FREQUENCY CCSF). The CSF command is used to assign a 
new input or output frequency Cortority) to a station. 


Syntax: 
* CSE statton~-speci fier frequency 
0 
Semantics: 
The codes [I and 9 specify whether the frequency applies on input 


or output. "Frequency™ must be an tnteger tess than or equal to 
255. 


Example: 
acsF Tp2 I 250 
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CHANGE STATION MAXIMUM RETRY (CSM). The CSM command is used to give a 
new value to the number of times the Network Controi tries to retransmit 
a message when there are errors. 
Syntax: 

* CSM station~-specifier retries 


Semantics: 


"Retries” must be an integer up to two digits Long. 
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CHANGE STATION QUEUE (CSQ). The CSQ command is used to re-route 
messages bound for one station to some other station instead. 


Syntax: 
* €59 station-specifier~1 station-specifier-2 

Semantics: 
"Station-spaecifier-1" is the original stations and *station= 
specifier-2" 1s the new station. If “station~specifter~1" and 
"statton-specifier-2" are the same» routing reverts to the 
original station. 

Example: 
a CSQ TD1 TD4 


Messages which would ordinarily go to station TD01 wilt now go to 
Station TD4. 
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CHANGE STATION READY CCSR). The CSR command is used to mark a station 
as ready or not ready. The Network Controller does not attempt to do 
any input/output on a station that is not ready. 


Syntax s 
* CSR station~speci fier 
N 


Example: 
2 CSR 3R 


io Boe 1; 


</ICS FOb* > AXHESK ‘T K 
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CHANGE STATION TRANSMISSION NUMBER (CST). The CST command is used to 
give a new value to the transmission number of a station. 


Syntaxs 
*« CST station~specifier transmisston“number 
Q 
Semantics: 


The codes I and O indicate whether the input or output transmission 
number is to be changed. 


Example: 
2 CST TD1 I 35 
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FORMATUPDATE CUPD) COMMAND. There ts one network control command to 
update formats. This command is onty provided in the advanced and 
total versions of GEMCOS. The UPD command makes updated formats 
available to all stations in the MCS networke Formats can be updated 
using the UPDATEFMT option of the control command or by employing 

the Format Generator. By either nethod»s updated formats are conse- 
quently placed in the MCSFORMATS fite. The old version of the format 
remains available throughout the network untii the UPD command is 
enterede Upon entry of the commands updated formats are available. 


Syntax: 
* UPD 
Semantics: 


This request causes ali previously-modified formats to be 
updated and made availiable to all stations in the network. 


3-ai71i 


AUDIT & RECOVERY COMMANDS. 
The existence of these commands is controlted by the AUDI TASSIGNMENT> 
AUDITTRANSACTIONS» and RECOVERY stateagents of the Program section. 


REFRESH COMMAND CREF). The REF command is used to recatl the most 
recent audited output message. 


Syntax: 
* REF 


Semantics: 


This request causes the MCS to display the last audited output 
message for the station. An error Is returned af there are no 
output messages for the station. 


Example: 
3 REF 
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CLEAR DISABLED PROGRAM CCLE). The CLE command is used to clear disabled 
programs and to cause recovery to be initiated. 


Syntax: 
* CLE <program=-speci fier> 

Semantics: 
If after clearing a disabled program recovery does not bagine at 
least one other program in the data base is still disablad-. When 


all programs are cleared» recovery of the data base initiated. 


Examples: 


a CLE PROG1 
a CLE 2 
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RECOVER DATA BASE CREC). The REC command is used to initiate recovery 
on a particular data base or on all data bases declared in TCL. 


Syntax: 
* REC {<database-speci fier>] 
Semantics: 


If no <database~specifier> is specifieds then recovery is initiated 
for alt data bases that are declared to this MCS. Otherwise>r 
recovery is initiated onty for the selected data base. If 

any programs in the data base are disabled at the time of the re- 
quests then an error message is displayed on the control station 
listing the numbers of the disabled program (s)- These programs 
can then be cleared using the CLE commands and recovery is then 
initiated. 


Examples; 
a REC 


a REC LIVEDB 
@ REC 0 
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RESET BUSY STATUS CRBS) COMMAND.j If a station as definei with 
TRANSACTIONMODE = TRUE» the statton can become locked into a busy 
status. This occurs when a station sends a message to a synchro- 
nized recovery program and the program does not responde Should 

a station receive Error 106» this indicates that the station has a 
busy statuse The RBS network control command must be entered fro a 
control station or from the SPO. 


Syntax: 
* RBS station~speci fier 

Semantics: 
Entry of this command causes the station “station-specifier”™ to 
be taken out of a busy status.e. Once the command is processed» 
the station operator may enter input at the station. If the 


Station is not busy» this conmand has no effect. 


Examples: 


2 RBS STATION? 
a2 RBS 3 
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SECTION 4 


MESSAGE ROUTING 


GENERAL e 
Messages are routed to Application Programs by a GEMCOS MCS by one of 


three methods» depending on the program classification defined for 
each Apptlicatiton Program in the <PROGRAM section> of TCL. The three 
types of classification are Assignments Utility» and User (refer to 
ASSIGNMENT PROGRAMS» UTILITY PROGRAMS» and USER PROGRAMS in section 3). 


The routing ts further defined by the <INTERFACE statement> tn TCL. 
Each program uses one of three tnterfaces: NONPARTICIPAT ION,» 
PARTICIPATION» or MCS Crefer to NONPARTICIPATIONs PARTICIPATION, and 
MCS in section 3). 


Thus seven combinations of program classification and interface are 
possible: three interfaces for Assignment Programs» three interfaces 
for Utility Programs» and one interface CPARTICIPATION) for User Pro- 
gramse The following example Lists all seven meaningful TCL 
descriptions: 


PROGRAM X1 UTILITY: 


TITLE = X. % OPTIONAL 
INTERFACE = NONPARTICIPATION. 
RESIDENCE = DOISK. % OPTIONAL 


PROGRAM X2 UTILITY: 
TITLE = X. % OPTIONAL 
INTERFACE = MCS. 


OPENMESSAGE = TRUE. % OPTIONAL 
ATTACHMESSAGE = TRUE. % OPTIONAL 
RESIDENCE = DISK. % OPTIONAL 
PROGRAM X3 UTILITY: 
TITLE = X. 2 OPTIONAL 
INTERFACE = PARTICIPATION. & OPTIONAL 
COMMONSIZE = 100. ~% OPTIONAL 
TRANCODE = XC1e1). % OPTIONAL 
OPENMESSAGE = TRUE. % OPTIONAL 
ATTACHMESSAGE = TRUE. % OPTIONAL 
DETACHMESSAGE = TRUE. % OPTIONAL 
RESIDENCE = DISK. *% OPTIONAL 
PROGRAM X4& USERS 
TITLE = Xe % OPTIONAL 
INTERFACE = PARTICIPATION. 2 OPTIONAL 
COMMONSIZE = 100. % OPTIONAL 
TRANCODE = XCi1el). % OPTIONAL 
OPENMESSAGE = TRUE. % OPTIONAL 
RESIDENCE = DISK. % OPTIONAL 
EXECUTE = ONDEMAND. & OPTIONAL 


PROGRAM X5 ASSIGNMENT: 


TITLE = X. % OPTIONAL 

INTERFACE = MCS- 

DPENMESSAGE = TRUE. % OPTIONAL 

RESIDENCE = DISK. % OPTIONAL 
PROGRAM X6 ASSIGNMENT: 

TITLE = Xe Z OPTIONAL 

INTERFACE = NONPARTICIPATION. 

RESIDENCE = DISK. % OPTIONAL 

EXECUTE = MANUAL. Z OPTIONAL 
PROGRAM Xf ASSIGNMENT: 

TITLE = X. & OPTIONAL 

INTERFACE = PARTICIPATION. Z OPTIONAL 

COMMONSIZE = 100. % OPTIONAL 

TRANCODE = XC1»1). ZX OPTIONAL 

OPENMESSAGE = TRUE. Z OPTIONAL 

RESIDENCE = DISK. 2 OPTIONAL 

EXECUTE = BOJ. % OPTIONAL 


Several generai comsgents apply to the above TCL 


ae 


descripti ons: 


More than one <TRANCODE statement> is permissible 
where a <TRANCODE statement> is optionally or 


mandatorily required. 


be In a <PROGRAM description> no other <PROGRAM statement> 
may occur more than once. 


Ce The following defaults are in effect: 


1) Default for 


2) Default for 
3) Oefault for 
&) Defauit for 


5) Default for 


DPENMESSAGE» ATTACHMESSAGE» and 
DETACHMESSAGE is FALSE. 


RESIDENCE is CORE. 
COMMONSIZE ts 60. 
INTERFACE ts PARTICIPATION. 


EXECUTE 1s MANUAL. 


Each of the seven coabinations can be used to maximnua 


particular program. 
the program to GEMCOS in 


TCL for each situation. 


advantage for a 


The following discussion relates how to describe 


A user might have a program which was written prior to the acquisitton 
of GEMCOS. Such a program might not require any GEMCOS options other 
than the capability of remote execution by authorized personnal. This 
program should be described in TCL as le Its program name would be 
associated in the <ACCESSCONTROL statement> with access keys which 

are then assigned to authorized personse Since the program is defined 
as a Utility Program» tt could be executed from any station. Since it 
used the NONPARTICIPATION interface» it would not have to be reconapiled 
to conform to the GEMCOS Commonc-area header or to the B 1800/8 1700MCS/ 
Network Controller interface. 


The user may be using CANDE and ODESYs» which are MCS programs. Station 
operators would Like the ability to switch between CANDE and ODESY. 
Without GEMCOS» both CANDE and ODESY must be shut down and brought back 
up to switch a station. This is very inconvenient to the rest of the 
station operators. However» if both CANDE and ODESY are defined as X2 
programs» GEMCODS» as a supervisory MCS» can switch a station between 
these two MCS programs on demand from the station without interrupting 
the rest of the stations. Since sessions with CANDE and ODESY are to 
be initiated remotely» they are described as Utility Programs. Since 
both are MCS programs» they must use the MCS interface. 


The user may wish to design a program which could be initiated renotely 
and take advantage of the GEMCOS formatting capability. To support 
remote executions it must be a Utility Program. If formatting is to 
take places trancodes must be defined and a Commonmarea header is 
required. The X3 TCL description would be used. 


A situation might arise tn which there are several stations» 2ach 
requiring access to several data bases. It would be undesirable to 
have one Large program handle all the data bases. Conversely» writing 
several smatt modular programs for each data base wouid de more effi-~ 
cient but would require the user to repeatedly execute and halt these 
programs» an esvneciaity awkward and time-consuming process for rarely 
used programs that process only a few transactions before the next 
program must be executed. A preferapnle solution would be to assign 
trancodes for each data base accessing method» to write modular pro- 
grams to handle these trancodes» placing these programs in the mix 
{possibly as diskcresident programs)» and to describe a series of X& 
programs in TCL. The trancodes wauld be used to switch messages from 
any of the stations to any of the programs Cand could be used to take 
advantage of formatting). 


The user may have the Remote Job Entry (RJE) packagee RJE is an MCS 
which requires a tine to a host system. [t would be exe:uted fros the 
supervisory consote printer or a card reader» not by the host systen. 
If the host system is occasionally used by some program other than 

RJE which runs under GEMCOS» the host system has to be included tn the 
remote file opened by GEMCOS.j GEMCOS would allow RJE to gain access to 
the host system if RJE was described as a X5 programe RJE uses the MCS 
interface and normaily communicates with the same stations making it an 
Assignment Program. 


In certain applications the program attaches itself to stations. It 

as etther undesirable or impossible for stations to initiate the pro- 
grame Perhaps a station is to be dedicated to a program or the sta- 
tion ts an outputcronly device. Programs which determine the message 
routing via remote file attachment can be accommodated by being 
described as either an X6 or X7 program. If no GEMCOS capabilities 

are required» the X6 description suffices. If GEMCOS ts to provide 
functions Cformatting» audit» screen wraparounds etc.) for the programs 


the X7 description is necessary. 


&n4 


SECTION 5 


ACCESS CONTROL 


GENERAL. 
B 1800/8 1700 GEMCGS provides three types of access control: 


ae Requiring a user to sign on with a valid access code 
before accepting any messages. 


be Restricting user codes to a spectfied station or stations. 


ce Restricting each access code to specified program 
and/or transaction codes. 


Access control is defined in three sections of TCL. The <PROGRAM 
section> defines each program and the transaction codes for each pro- 
grams the <ACCESS CONTROL statement> defines the access todes and the 
programs and transaction codes that each access code can uses and the 
<STATION section> defines the stations in the network ani the access 
codes required to sign on at each station. 


A GEMCOS MCS for an online systen with three programs (a User Program 
with trancodes UPDATE and INQ» a User Pogram with trancode EDIT» and a 
Utility Program) could be generated without security using the following 
TCL deck: 


CONTROL = GENERATEs LIST» COMPILE. 
GLOBAL = 
CHANGERE QUESTS = TRUE. 
PROGRAMBOJEOJ = TRUE. 
SYSTEMHALT = TRUE. 
MAXTEXTSIZE = 1980. 
BEGIN 
PROGRAM PAYROLL USER: 
TITLE = PAYROLL. 
TRANCODE = UPDATE. 
TRANCODE = INQ. 
PROGRAM TEXTEDIT USER: 
TITLE = USERPACK/TEXTEDIT/. 
TRANCODE = EDIT. 
PROGRAM GAME UTILITY: 
TITLE = GAME. 
STATION TDS8A: 
STATION TD8B5 
STATION TO8C: 
END. 


The fottlowing TCL deck can be used to add user codes to this exanrple 
Each person is required to sign onto GEMCOS with a valid user 
code before using the system. Once signed ons the user in this examole 


system. 


is permitted to use any program or trancode. 


any station: 


CONTROL = GENERATE» LIST» COMPILE. 
GLOBAL * 
CHANGEREQUESTS = TRUE. 
PROGRAMBQJEOJ = TRUE. 
SYSTEMHALT = TRUE. 
MAXTEXTSIZE = 1980. 


BEGIN 
ACCESSCONTROL: 
ACCESSKEY JOE = ALL. ® ALL MEANS THIS 
ACCESSKEY JIM = ALL. % ACCESSCODE [5 
ACCESSKEY TOM = ALL. Z ALLOWED TO USE 
Z PROGRAMS AND 
~% TRANCODES. 


PROGRAM PAYROLL USER: 
TITLE = PAYROLL. 
TRANCODE = UPDATE. 
TRANCODE = INQ. 

PROGRAM TEXTEDIT USER: 
TITLE = USERPACK/TEXTEDIT/. 
TRANCODE = EDIT. 

PROGRAM GAME UTILITY: 
TITLE = GAME. 

STATION TOBA: 

SIGNON = TRUE. 


VALIDACCESSKEYS = ALLj &% ALL MEANS ALL 
STATION TO8B: % USERCODES CAN 
SIGNON = TRUE. 2 SIGN ON AT 

VALIDACCESSKEYS = ALL.~j 2% THIS STATION 


STATION FD8C3 
SIGNON = TRUE. 
VALIDACCESSKEYS 


ALL. 
END. 


The user may sitgno-on at 


ALL 


The preceding TCL deck provides three access codess JOE» JIM» and TOM. 
All three codes can be used at any station and» once signed on at 

any stations any program or transaction code can be usede A more 
restrictive system can be defined. For example» user code TOM could be 
restricted to trancode EDIT onty» and user code JIM to trancode INQ 

and program GAME» white aliowing user code JOE to use all trancodes 

and programs. The TCL deck with this more restrictive atcess security 
scheme would be as follows: 


CONTROL = GENERATE» LIST» COMPILE. 
GLOBAL : 
CHANGEREQUESTS = TRUE. 
PROGRAMBOJEQJ = TRUE. 
SYSFEMHALT = TRUE. 
MAXTEXTSIZE = 1980. 


BEGIN 
ACCESSCONTROL: 
ACCESSKEY JOE = ALL. 
ACCESSKEY JIM = INQ» GAME. 
ACCESSKEY TOM = EDIT. 


PROGRAM PAYROLL USER: 
TITLE = PAYROLL. 
TRANCODE = UPDATE. 
TRANCODE = INQ. 
PROGRAM TEXTEDIT USER: 
TITLE = USERPACK/TEXTEDIT/. 
TRANCODE = EDIT. 
PROGRAM GAME UTILITY: 
TITLE = GAME. 
STATION YOBA: 
SIGNON = TRUE. 
VALIDACCESSKEYS 
STATION YTOBS: 
SIGNON = TRUE. 
VALIDACCESSKEYS 
STATION TDSC: 
SIGNON = TRUE. 
VALIDACCESSKEYS 


ALL. 


ALL. 


ALL. 
END. 


Finaity» certain user codes may 


be restricted to particular stations. 


For example» to atlow JIM to signcvwon only at station TD8A» JOE at TOBA 


and TD8C» and TOM at ali three stations» the TCL deck would 


follows: 
CONTROL = GENERATES 
GLOBAL = 
CHANGEREQUESTS = 
PROGRAMBOJEDJ = 
SYSTEMHALT = TRUE. 
MAXTEXTSIZE = 
BEGIN 
ACCESSCONTROL: 
ACCESSKEY JOE 
ACCESSKEY JIM 
ACCESSKEY TOM 


LIST» 


1980. 


be as 


COMPILE. 


TRUE. 
TRUE. 


ALL. 
INQ» 
EDIT. 


GAME. 


PROGRAM PAYROLL USER: 


TITLE = 
TRANCODE = 


TRANCODE = INQ. 


PAYROLL. 
UPDATE. 


PROGRAM TEXTEDIT USER: 


TITLE = 
TRANCODE = 


USERPACK/TEXTEDIT/. 
FOIT. 


PROGRAM GAME UTILITY: 


TITLE = GAME. 
STATION YDBA: 
SIGNOGN = TRUE. 
VALIDACCESSKEYS 
STATION TO8B= 
SIGNON = TRUE. 
VALIDACCESSKEYS 
STATION TD8C: 
SIGNON = TRUE. 
VALIDACCESSKEYS 
END. 


ALL. 


it 


TOM. 


JOE» TOM. 


SECTION 6 


MESSAGE FORMATTING 


GENERAL-} 

This section illustrates several practical uses for message formatting. 
It is not intended as a complete survey of the topic. (CRefer to FORMAT 
AND FUNCTION STATEMENT LISY and to DEVICE SECTION in section 3 for a 
description of formatting syntax and semantics.) 


In an onttine environment proper message formatting ts essential for 
effective use of the terminal. Properly formatted tnput and output 
messages aid readability and assist both the occasional terminal user 
and the full-time terminal operator. The formatting of input and out- 
put messages is therefore a required function that must de perforwed by 
each Application Program or by some other part of the systen. 


When an Application Program formats its onn input/output messages» 
changing or modifying a message format becomes a major problen Ce.gee 
when existing formats are not suitable for a new terminal type). If 
the formatting is *hard=coded™ tato the Application Programs» such 
changes require program patches and recompilations and can potentially 
introduce new problems. In additions this approach requires sore 
memory to store the Fornrnatting code that must be duplicated for each 
program. 


These problems are avoided by using the Generalized Formatting module 
in the MCS. With this approach» the Formatting code is stored in only 
one locations the MCS.j Thus» messages can be changed without modifying 
the Application Programs. Since Formatting code is generaiized in the 
MCS and is based on a disk file (MCSFORMATS)» format changes can be 
implemented by merely updating the disk fitite.w The MCS does not have 

to be modified. 


GEMCOS_ EDITING PHRASES. 
The most common GEMCOS editing phrases are described in the following 
table: 


Editing Phrase Description 


ALPHA ITEM TYPE In the form A<integer>» this phrase moves 
<integer> bytes from the raw message to the 
edited message. 


INTEGER ITEM TYPE In the form I<integer>» this phrase moves 
<integer> bytes from the raw message to the 
edited message (Cas does ALPHA ITEM TYPE)» 
and at also verifies that data being entered 
contains only digits and blanks (no embedded 
blanks). It aiso right justifies numbers 
and inserts leading zeroes where required on 
input. 


Editing Phrase 


SKIP FIELD 


ES8CDIC STRING 


HEXADECIMAL STRING 


FUNCTION CALL 


LOCATION 
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SPECIF TIERS 


Description 


In the form X<integer>» this phrase inserts 
<integer> spaces into the message - 


In the form "<character string>*» this phrase 
places a character string into the formatted 
message o1 output. 


In the form &“*<hexadecimal character string>*» 
this phrase ts composed of digits O thru 93 and 
letters A thru Fe It ts used th® sam2 way as 
EBCDIC STRING to insert characters in the 
messages however» it can be used to insert any 
character including nonprintabte EBCDIC char- 
acters. The primary use of this phrase ts to 
insert terminal control characters Ceegea» 
carriage returns» tine feeds)» many of whitch 
are nonprintable. 


In the form 'T<function name>» <al pha iten 
type>/<integer item type>»<integ2a2r>s this 
phrase converts any string six characters or 
less to any other string six characters or 
fesse. The <function name> is used to specify 
which function ts to be used in the REPLACE 
operation. The <alpha item type> or the 
<internal item type> is used to specify the 
length and type of the external character 
string and the integer is used to specify 
the length of the internal charazter striage 


In the form a&<sign><integer>» this phrase 
overrides the normat mode of sequential opera- 
tion of the formatter. It may be required to 
skip around in the message (Ceeger» if specific 
fietds are to appear ina different order on 
the terminal than they come from the program). 
The @#<integer> skips <integer> bytes forward, 
the a-<integer> skips <integer> adytes 
backward. 


QUTPUT_FORMATTING EXAMPLE. 

In this example it is assumed that the purpose of a program is to 
return information about records tn a customer file» and that the pro- 
gram has the following output area and is sending the foltowing data: 


COBOL Description sending Data 
01 SAMPLE-OUTPUT-AREA. 
05 CUSTOMER“NAME PIC X(30). THE WILSON FOOD STORES 
05 ACCOUNT-NBR PIC 9(6). 220030 
05 TOTAL~AR“BALANCE PIC 22Z»2727.99 159365250 
05 TERMS PIC X. 3 
* 7 = 7 DAYS 
t 1 = 10 DAYS 
a C = coD 
* 3 = 30 DAYS 
& 05 CURRENT“BALANCE PIC ZZ2Z»#ZZZ-88 8»420.1) 
05 ADDON“PERCENT PIC 229. 9 
05 OVER“7-DAYS-BALANCE PIC 22275222.99 824.10 
05 DATE“LAST“INVOICED PIC 99/99/99. DB8/01L/77 
05 OVER“14-DAYS“BALANCE PIC Z2Z*272.99 392B101) 
05 CREDIT-LIMIT PIC 7(6). 20000 
05 OVER-21-DAYS"“BALANCE PIC 772»777.99 200 
05 PRICE-CODE PIC 9. 2 
05 DELINQUENT-FLAG PIC 9. 1 
* 1 = YES 
* 0 = NOD 
05 OVER~28-DAYS“BALANCE PIC 22ZZ»Z77.99 29840.2) 
05 WAREHOUSE PIC XX. Al 
05 ITEM~SUBSTITUTE-FLAG PIC 9. 1 
* 1 = YES 
* 0 = NO 
05 CREDIT“BALANCE PIC ZZZ9Z2Z.99 200 


The following TCL could be used to format the output messages for a 
TD700 which has eight Lines of 32 characters each? 


CONTROL = GENERATE» LIST» COMPILE. 
GLOBAL = 
CHANGEREQUESTS = TRUE. 
PROGRAMBOJEOJ = TRUE. 
STATUSREPORTS = TRUE. 
SYSTEMHALT = TRUE. 
MAXTEXTSIZE = 19860. 


FORMAT 
OUT700 C 47*0C0000"%» Z CLEAR SCREEN AND HOME CURSOR 
% LINE 1 
XL»A30 Xl» 
% LINE 2 
PACCT~"*sT6e2X2e" TOTAL *» X4nrAl0» 
% LINE 3 
"TERMS~*eAlsX6e"* CURRENT*» X22 A1L0> 
% LINE & 
"ADDON~"*eA3SeX&e"OVER 7*eX2eAl0>» 
*% LINE 5 
"LIJIT" sABeXie"OVER 147% 2X2eA10» 
% LINE 6 
"LIMIT“*sA6»Xis"“OVER 21%29X2eAl10> 
% LINE 7 
PPRICE“"sTlsX1ls*DF-"elisXis"OVER 28" »X2eAl 0» 
*% LINE 8 


"WHSE“"sAZoXle"SUB-"*e Tis Xle*CREDIT"»X2sA1) ). 
BEGIN 
PROGRAM SAMPLE USER: 
TITLE = GEMCOSPACK/GEMCOS/SAMPLE. 
TRANCODE = CUSTIN. 
STATION TODAS 


TRANCODEPOSITION = 1. 
STATION TO78: 

TRANCODEPOSITION = i. 
STATION TO7C: 

TRANCODEPOSITION = 1. 


DEVICE TDO700: 
STALIST = TDO7A» TO7B» TO7C. 
FORMATSOUT: 
OUT700 = ARINFO. 
END. 


Figure 6-1 depicts the formatted output of the data returned from the 
Application Program Cwith the forraat-ID fietd of the header sat to 
ARINFO) and in turn sent to one of the stations Listed under the device 
"“TO700". The MCS uses format OUT700 to format the message. 


THE WILSON FOOD STORES 
ACCT-220030 TOTAL 
TERMS -3 CURRENT 
ADDON- 9 OVER 7 


ON OFrFr UI 


L/I-08/01/77 OVER 14 
LIMIT- 20000 OVER 21 
PRICE-2 DF-1 OVER 28 
WHSE-Al SUB-1 CREDIT 


OOO 90O00 0 


Figure 6-1. Sarapte Formatted Output 
Data Display 


It may be desirable to use functions to convert the data coming from 
the Application Program to a more readable form. For examples in the 
preceding format» the TERMS code 3 is not very definitive. It would be 
better to display something more descriptive like 30 DAYj To do this» 
the following function is defined: 


FUNCTION 
TERMS CEXTERNALZ ALPHA» INTERNALS ALPHA) C€ 
"= ¢ DAY*3*7 "5 
"10 DAY"3"1"> 
"30 DAY™2"3">» 
“COD “3s "C")- 


This function description converts "7" to “7 DAY*» "17° T0 "10 DAY">» 
etce DELINQUENT“FLAG and ITEM“SUBSTITUTE"FLAG displayed as a "1" 
or a “0” could also pe changed to display a Yor N by defining the 
foliowing function: 


FUNCTION 
BINARYOUT700 LEXTERNALZ ALPHA» INTERNALSINTEGER] ( 
ays bic! Was 


To take advantage of these functions» the calls must be inserted in the 
format being used» necessitating the following change to Line 3: 


% LINE 3 
"TERMS~"*s TCTERMS» A601) »X1eo* CURRENT" » X20 A109 
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Lines 7 and 8 would then read as follows: 


% LINE 7 

"PRICE=*sTLloXl»"DF-"» TCBINARYOUTZOOsALa LI oXIe "OVER 28"» X2eA105 
X LINE 8 

"WHSE "er AZ eX lo *SUB~"» TCBINARYOUTZOOsA191)oX1e "CREDIT" »X2eA10).~ 


The TCL deck now appears as follows: 


CONTROL = REGENERATEs LIST. % IT IS NOY REQUIRED TO GENERATE AND 
COMPILE % THE MCS SINCE WE ARE ONLY CHANGING FUNCTIONS 
AND FORMATS 
GLOBAL: 
CHANGEREQUESTS = TRUE. 
PROGRAMBOJEDJ = TRUE. 
STATUSREPORTS = TRUE. 
SYSTEMHALT = TRUE. 
MAXTEXTSIZE = 1980. 
FUNCTION 
TERMS CEXTERNALS ALPHA» INTERNALSALPHA] C 
" 7 DAY™"3"7"» 
"19 DAY*"s"1">» 
"30 DAY"3"73"> 
“COD "s"C™)» 
BINARYOUT700 CEXTERNALSALPHAsINTERNALSINTE GER] C€ 
FORMAT 
OUT700 € &"0C0000", Z CLEAR SCREEN AND HOME CIJRSGR 
& LINE 1 
XL »A30eX1l>» 
% LINE 2 
"ACCT-*eT6aX2e" TOTAL *» X4nA10 » 
2 LINE 3 
"TERMNS<-"sTCTERMS © A621)» Xl» "CURRENT "9 X20 ALD » 
*% LINE 4 
"ADDON" sA32X4e"0OVER T7* 9X20 A109 
Z LINE 5 
"LJI“"sABeXle*OVER 1479 X2eA10» 
% LINE 6 
“"LIMIT“"sAbeXls*OVER 21"%9X2e A1L0» 
Z LINE 7 
"PRICE" es TisXLle*DF“"sTCBINARYOUT700c AL»e1)» Xie*DVER 28" >» 
X29 A110» 
% LINE & 
"HHSE~"»A2ZeX1e"*SUB"“"»TCBINARYOUT7OOs»AL»o1)» Xie *CREDIT™» 
X27A10). 


6-6 


BEGIN 
PROGRAM SAMPLE USER: 
TITLE = GEMCOSPACK/GEMCOS/SAMPLE. 
TRANCODE = CUSTIN. 
STATION TDA: 
TRANCODEPOSITION = ie 
STATION TO7B: 
TRANCODEPOSITION = Il. 
DEVICE TD?00: 
STALIST = TO7A» TO7B»e TOC. 
FORMATSOUT: 
o0uT700 = ARINFOQ. 
END. 
Figure 672 depicts the formatted output data returned from the Appltica- 
tion Programs and forwarded to the stations as a result of the function 
description and modified TCL decke 


THE WILSON FOOD STORES 
ACCT-220030 TOTAL 
TERMS-30 DAY CURRENT 
ADDON- 9 OVER 7 
L/I-08/01/77 OVER 14 
LIMIT- 20000 OVER 21 
PRICE-2 DF-Y OVER 28 
WHSE-Al SUB-Y CREDIT 


f- 
co Ul 
ww w 
No CO & 
CON NH OV 
@ 


a et 


e 


gO 
10 
10 
10 
00 
20 
00 


Figure 672. Exanaple Formatted Qutput 
Data Display for Redefined 
Foras Function 


If two 


TD830s Chaving 24 lines of 80 characters each) are now added to 


the networks a new format is required to take advantage of the larger 


screen. 
for recarrangement of the data to make it more readable. 


The larger screen permits more descriptive headers and allows 


be used to convert i and 0 to YES and NO rather than the more cryptic 
Yand Ne. This requires the defining of a new functions 


FUNCTION 
BINARYOUT800 CLEXTERNALZ ALPHA» INTERNALSINTEGER] C€ 
"YES"S"71"> 
"NO"S"0"). 


AND A NEW FORMAT: 


OUTBOO € 4"0C0000"%» Z CLEAR SCREEN AND HOME CURSOR 


yd 


2 


yA 


The new stations and the new device type must be defined» 


LINE i 

X17>"CUSTOMER NAMES» X2eA3024"0D"» Z &4"°0D" IS CARRIAGE RETURN 
LINE 2 

4"°0D"» Z LEAVE BLANK LINE 
LINE 3 


"ACCOUNT NUMBER» X5eT6e2X15e"TOTAL A/R BALANCE» X22A1024*0D" » 
LINE 4 
"TERMS* » X14 eT CTERMS sA6e1l )»X1LSe"CURRENT* »XLieA1D»4"0D"> 
LINE 5 
"ADDON RATE Me XP eAS w*Z "eo X1LI7e>" OVER 7 DAYS* 9 X72 AL) ep 4*0D"% » 
LINE 6 
"DATE LAST INVOICED™» XL»>ASeXL3e"OVER 14 DAYS*eX7eA1004" 0D" > 
LINE 7 
"CREDIT LIMIT*» X7eA3eo "eo "eo AS eo XI4>"OVER 21 DAYS» X77 A10>4&* 0D" » 
LINE 8 
"PRICE CODE*sX9eITisatis Z SKIP OVER SUBSTITUTE FLAG 
XZ20e"OVER 28 DAYS*9 X77 A1024"0D" » 
LINE 9 
"WAREHOUSE" »oX10sA2eati» Z SKIP OVER DELINQUENT FLAG 
XL 9s "CREDIT" »XL3eA1024" 0D" >» 
LINE 10 
"SUBSTITUTE FLAG"»X422-24» %Z SKIP BACK TO GET SUBS FLAG 
TCBINARYOUT8005A 301 )9X18e2"DELINQUENT FLAG*™ »X4&» 
X4e2ad412> Z SKIP FORWARD TO GET DELINQUENT FLAG 
TCBINARYOUTBO02A321)). 


resulting in 


the following TCL deck: 


CONTROL = REGENERATE» LiIST.j Z IT IS NOT REQUIRED TO GENERATE AND 


4 COMPILE THE MCS SINCE WE ARE ONLY CHANGING FUNCTION,» 
yA FORMAT» STATION AND DEVICE DEFINITIONS. 


GLOBAL: 


CHANGERE QUESTS = TRUE. 
PROGRAMBOJEOJ = TRUE. 
STATUSREPGRTS = TRUE. 
SYSTEMHALYT = TRUE. 
MAXTEXTSIZE = 1980. 


A function can 


FUNCTION 


TERMS CEXTERNALZS ALPHA» INTERNAL? ALPHA) ( 
“ ¢ DAY"S"7"> 
"10 DAY":"1"> 
"30 DAY": "3"%> 
“COD "s"C*)» 
BINARYOUT700 CEXTERNALS ALPHA» INTERNALS INTEGER] C€ 


Oy s wi", 


BINARYOUT800 CEXTERNALSALPHAsINTERNALSINTEGER] C 
"YES" T1"» 
"ND *3"°0"). 
FORMAT 
OUT700 €C 4*90C0000"%» Z CLEAR SCREEN AND HOME CURSOR 
% LINE 1 
X1ivA30eX1» 
2 LINE 2 
PACTCE~“*e T6eX2e"TOTAL*» X42 A109 
% LINE 3 
"TERMS" TCTERMS»= A601) 9 XLle "CURRENT » X22 AL0>» 
% LINE & 
"ADDON“*sASeX4e"OVER 7*eX2eA10» 
% LINE 5 
"LII~"*rABeXis"OVER 14759X2eA10> 
*% LINE 6 
"LIMIT-"*sA6beXTe"DOVER 21"%5X2eA10» 
% LINE 7 
"PRICE" + TieXie*DF-*»sTCBINARYOUTZOO PAL» 1d eX» “OVER 2B" > X2rAL0> 
2 LINE 8 
PWHSE "es AZo XLle*SUB-"»+TCBINARYOUTZ0I0 »ALo ldo X1> "CREDIT" » X2»> A110)» 
OUT800 € 4"0C0000"» 5 CLEAR SCREEN AND HOME CURSOR 
% LINE tl 
Xiv» “CUSTOMER NAMES" »X2eA3024"0D"» Z 4700" IS CARRIAGE RETURN 
2 LINE&E 2 
A°0D"» Z% LEAVE BLANK LINE 
% LINE 3 
"ACCOUNT NUMBER» X5e 160 XL5e9 "TOTAL A/R BALANCE *e9 X22 A1L0 2470)" » 
% LINE & 
"TERMS * eX 14eTCTERMS 0 A5 91 do X1Se* CURRENT *o X1L1eA102 4"0D"> 
% LINE 5 
"ADDON RATE*®X9ePASe "Zo XL7 eo "OVER 7 DAYS*e X7eA1024"0D" >» 
2 LINE 5 
"DATE LAST INVOICED» XLeABe X1L3e> "OVER 14 DAYS" »X7rAL094&"00"> 
*% LINE 7 


"CREDIT LIMIT» X7 es ASe "oe "we ASeX1L&4e"OVER 21 DAYS*» X7eAL0P4"0D" » 
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% LINE 8 
"PRICE CODE*»X9eITisdtis ZX SKIP OVER SUBSTITUTE FLAG 
X20e"OVER 28 DAYS*»X7eA1024"0D">» 
% LINE 9 
"“WAREHOUSE™ »X10%A2eatl» ZX SKIP OVER DELINQUENT FLAG 
X19o"CREDIT™ > X13» A1024°0D">» 
X LINE 10 
"SUBSTITUTE FLAG*»X4ea-24» % SKIP BACK TO GET SUBS FLAG 
TCBINARYOUT&SOO »pA3 51) 5X18 »>"DELINQUENT FLAG*™»X4&» 
X4eatl2» ZX SKIP FORWARD TO GET DELINQUENT FLAG 
TCBINARYOUT800>A351)). 
BEGIN 
PROGRAM SAMPLE USER: 
TITLE = GEMCOSPACK/GEMCOS/ SAMPLE. 
TRANCODE = CUSTIN. 
STATION TD7A: 
TRANCODEPOSITION = 1. 
STATION TD7B: 
TRANCODEPOSTTION = 1. 
STATION TD/7C? 
TRANCODEPOSITION = 1. 
STATION TOSSA: 
TRANCODEPOSITION = i. 
STATION TDSB: 
TRANCODEPOSITION = 1. 
DEVICE T0700: 
STALIST = TOA» TO?B» TOC. 
FORMATSOUT: 
DUT700 = ARINFO. 
DEVICE 10800: 
STALIST = TD8A» TD8B. 
FORMATSOUT: 
OUT800 = ARINFO. 
END. 


With the new stations properly defined» the Application Program does 
not have to specify the type of terminal its response ts to be sent to. 
When it sends a message to the MCS with the format-iD set to ARINF Op» 
the MCS uses the appropriate format for the specific device type. If 
the message is in route to station TD7A» TD7B» or TD7C» it appears a3n 
the screen exactly as in the previous example. However» if it is gotng 
to TD8A or TD8Bs the MCS uses format OUT800 and displays the message 
depicted in figure 6~3. 


CUSTOMER NAME: THE WILSON FOOD STORES 


ACCOUNT NUMBER 220030 TOTAL A/R BALANCE 15,365.50 
TE RMS 30 DAY CURRENT 8,420.10 
ADDON RATE 9% OVER 7 DAYS 824.10 
DATE LAST INVOICED 08/01/77 OVER 14 DAYS 3,281.10 
CREDIT LIMIT 20 ,000 OVER 21 DAYS .00 
PRICE CODE 2 OVER 28 DAYS 2,840.20 
WAREHOUSE Al CREDIT .00 
SUBSTITUTE FLAG YES DELINQUENT FLAG YES 


Figure 6-3. Example Formatted Output 
for T0830 Terminal 


the program needs a message with the following three fields: a 6-char- 
acter transaction-code field containing CUSTINS a 6-digit field con- 
taining the customer account number; and a Aimdigit flag inforaning the 
program whether to include aging of the account balance in the 

response (1 = YESs 0 = NO). Two input formatting requirements are: 

to build a form on the screen for the operator on which to fill in the 


required information» and to form the data transmitted by the terninal 
for the Application Progr ame 
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The first objective is met by defining an output format which builds 
the form on the screen. This forrnat Clike ail output formats) cana be 
sent to the station by two means? it is sent if an Application Pro- 
gram sends a message to that terminal with the format~-ID of the header 
set to the appropriate format~-ID for that formats or the terminal 
operator can key in the format-ID directly. If it comes from a pro- 
grams it is filled with the data sent from the program. If the 

request comes from the stations the format is sent to the station as if 
a program had sent that format with the data area containing all spaces. 
Thuss the input form for the TD 700 terminals could be buiit using the 
following format: 


EMPTY 700 C 4&4"0CO0000%» 2% CLEAR SCREEN AND HOME CURSOR 
* LINE 1 
"CCUSTINI"»4"0D"> 
% LINE 2 
“CUSTOMER ACCOUNT NUMBER™»X20°[ "> A69"1"% > 
% LINE 3 
"RECEIVABLE AGING INFO? [> A3e"1"> 
4£"1200000005000000"). % PUT TERMINAL IN FORMS MODE 
2 AND TAB ONCE 


The DEVICE section for the TD700s must also be changed to read: 


DEVICE TO700: 
STALIST = TOA» TO7Bs» TOC. 
FORMATS OUT: 
OUT7090 = ARINFO. 
EMPTY700 = CSTFRM. 


Figure 6~4 depicts the display that would be sent by the MCS in response 
to the forms request (when the terminal operator transmits CSTFRMA). 


[CUSTIN] 
CUSTOMER ACCOUNT NUMBER [ 
RECEIVABLE AGING INFO? [ 


Figure 674. Example Input Form 
for T0700 Terminal 


The forswat for the TD830 terminalis is the same except for the forn 
deft delimiter and right delimiter which are (€ and Is respectively» on 
the T0700 and 4"1F"* and &*"1E"% on the TOD 830-2 Thuss the format can be 
described as follows: 


EMPTY800 € 4&4"0COQ0000"%» Z CLEAR SCREEN AND HOME CURSOR 
2 LINE 1 
A" LE oe" CUSTIN »4"1£00"> 
% LINE 2 
"CUSTOMER ACCOUNT NUMBER» X2e471F “ep Abe &*1LEDD*e 
2 LINE 3 
"RECEIVABLE AGING INFO? **p4"L1F*eA 32 471E%> 
4°27£6000005000000"). Z PUT TERMINAL IN FORMS MODE 
% AND TAB ONCE 


The DEVICE section for the 1D830 device would be: 


DEVICE 1D800: 
STALIST = TOBA» TD8B. 
FORMATSOUT: 
OUT&O0O0 = ARINFO. 
EMPTY800 = CSTFRM. 


Thus when the operator transmits CSTFRM from a TD830» the MCS returns 
the display depicted in figure 6-5. 


It ts also necessary to format the message from the station for the 
Application Programe The same format for both the 1T)700 and the 

T0830 can be used since both the TD700 and the 10330 send data in 

the same format CCUSTIN fottlowed by stx characters of aczount nuaber>r 
followed by three characters to indicate whether or not the response is 
to include aging information). 


Since the program expects ail or 0 for the aging flag» a function is 
used to allow the operator to enter YES» Y Cor 1 for 1)» and to enter 
NO» N Cor O for 0). This function is as follows: 


FUNCTION 
BINARYIN CEXTERNALZ ALPHA» INTERNALS INTEGER] (€ 
"YES™S "7175 
ays 1, 
Wyre eT 
FN sO" > 


MOPS OT) 
Now the format appears as follows: 
FORMAT 


IN € 
AbsTosTCBINARYINsA3e1)).~ 


(CUSTIN] 
CUSTOMER ACCOUNT NUMBER [ ] 
RECEIVABLE AGING INFO? [ | 


Figure 6~5. Example Input Form 
for TDO830 Terminal 


Finally» this format must be added to the FORMATSIN portion of the 
device description of both the TO700 and the 10830. The TCL is as 
foltows: 


CONTROL = REGENERATE» LIST.j Z% IT IS NOT REQUIRED TO GENERATE AND 


z COMPILE THE MCS SINCE WE ARE ONLY CHANGING FUNCTION» 
y 4 FORMAT» STATION AND DEVICE DEFINITIONS. 
GLOBAL: 


CHANGEREQUESTS = TRUE. 
PROGRAMBOJEOJ = TRUE. 
STATUSREPORTS = TRUE. 
SYSTEMHALT = TRUE. 
MAXTEXFSIZE = 198%. 


FUNCTION 
TERMS CEXTERNALZ ALPHA» INTERNAL SALPHA) ( 

" TF DAY"2"7"%>» 
"10 DAY": "1i"> 
20: OAL = oC 8 
“COD "s"C™)» 

BINARYOUT7OO CEXTERNALZ ALPHA» INTERNALS INTEGER] € 
sy. 2 wi” >» 

BINARYOUTB00 CEXTERNALZALPHAS INTERNALS INTEGER) C€ 
"YES" 71", 
"NO" 270" )>» 

BINARYIN CEXTERNALS ALPHA» INTERNALSINTEGER] (€ 
"YES™TI TL", 
ys wi "» 
"is wi] "> 


"NO"™2"0">» 
MON SO Je 
FORMAT 
OUT700 € &4"0C0000"%, Z CLEAR SCREEN AND HOME CURSDR 
2 LINE 1 
X1sAS0eXi» 
% LINE 2 
WACCT<"*eL62XZ2e"TOTAL*»> X4e A105 
% LINE 3 
"TERMS ~-*eTCTERMS» A601) eo XKLe "CURRENT » X29 A190» 
% LINE 4&4 
"ADDON="*sA3eX4e"DVER "9 X2eA10» 
% LINE 5 
"LII~"sABeXle" OVER 14%»X2eA105 
% LINE 6 
"LIMIT—*»A5eXils"BVER 21%9 X22 A110» 
% LINE 7 
"PRICE~"s Tle Xis*DF-"*»s TCBINARYOUTZOOpAL»1L)o Xi» “OVER 2B*»X2rAL0>» 
% LINE 8 
"“WHSE “"* sA2eX1ls"SUB-*»+TCBINARYSOUT7Z00» A121) 9X1» "CREDIT" »>X2r AL0>» 
BDUT8DO CC 47000000", 5 CLEAR SCREEN AND HOME CURSOR 
% LINE 1 
X1iZ7*e"CUSTOMER NAMES *»X2eA3024"0D"%» Z &*0D" IS CARRIAGE RETURN 
& LINE 2 
4&4"OD"» Z LEAVE BLANK LINE 
% LINE 3 
"ACCOUNT NUMBER™e+ X521T6eX15e "TOTAL A/JR BALANCE *»X2eA1024"0D0"% 5 
x LINE & 
"TERMS *eXL4eTCTERMS 2A5601) 2 X15e"CURRENT* »XLisA 1024"*0D" » 
Z LINE 5 
"ADDON RATE*e X9eASe*Z" eo XI7s "OVER £ DAYS*» X7eA1024"0OD" > 
Z LINE 6 
“DATE LAST INVOICED* > XL sASe XL3e"QOVER 14 DAYS”? oX7eA102 4700", 
* LINE 7 


“CREDIT LIMIT» Xf A350" o "eo ASeXL4e"OVER 21 DAYS "e X7vAL0 eG" 0D" >» 
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BEGIN 


% LINE 8 
"PRICE CODE™*»X9eT1lsatis Z SKIP OVER SUBSTITUTE FLAG 
X20 e2"0VER 28 DAYS*™»>X7e A102 4"0D"* » 
% LINE 9 
WWAREHOUSE™*»XLOsA2eatis Z SKIP OVER DELINQUENT FLAG 
X19 e"CREDIT™ »X13e2A10924"0D" » 
% LINE 10 
"SUBSTITUTE FLAG™*»X42a07-24» Z SKIP BACK YO GET SUBS FLAG 
TCBINARYDUTB00 » A353 21)59X18»"*DELINQUENT FLAG*™ »X4&» 
X4e04+125 Z SKIP FORWARD TO GET DELINQUENT FLAG 
TCBINARYOQUT800 pA3r1))> 
EMPTY700 (© 4&"0C0000"» Z% CLEAR SCREEN AND HOME CURSOR 
% LINE 1 
"CCUSTINI"»s4"0D">» 
%Z LINE 2 
"CUSTOMER ACCOUNT NUMBER* +» X20"[*» A607 1" 5 
X% LINE 3 
"RECEIVASLE AGING INFO? [*»A32" 3" > 
4"1200000005000000")» % PUT TERMINAL IN FORMS MODE 
2 AND TAB ONCE 
EMPTY800 € 4"7"0C0000"%» Z CLEAR SCREEN AND HOME CURSOR 
& LINE 1 
&S°1LF*s"CUSTIN®»4"71L EOD" » 
% LINE 2 
"CUSTOMER ACCOUNT NUMBER* + X2e"1F* 2A6e4"1E DD» 
Z LINE 3 
"RECEIVABLE AGING INFO? *"4"71F 2 AS e4"1E* > 
4"27£6000005000000")» X PUT TERMINAL IN FORMS MODE 
% AND TAB ONCE 
IN ¢ 
Abs lIbeTCBINARYINe A301) ).~ 


PROGRAM SAMPLE USER: 
TITLE = GEMCOSPACK/GEMCOS/ SAMPLE. 
TRANCODE = CUSTIN. 

STATION TOA: 
TRANCODEPOSITION = 1. 

STATION TO7B: 


TRANCODEPOSITION = 1. 
STATION TD7C: 
TRANCODEPOSITION = 1. 
STATION TOSA: 
TRANCODEPOSITION = 1. 
STATION TO8B: 
TRANCODEPOSITION = 1. 


DEVICE TDO700= 
STALIST = TOA» TO7Bs» TO7C. 
FORMATSIN: 
IN = CUSTIN. 
FORMATSOUT: 
OUT700 = ARINFO. 
EMPTY700 = CSTFRM. 


ig SS 


DEVICE TD800: 
STALIST = TOBA» TDS8B. 
FORMATSIN: 
IN = CUSTIN. 
FORMATSOUT: 
OUTBOO = ARINFO. 
EMPTY800 = CSTFRM. 
END. 


Figure 67-6 depicts the filled-in input form. When transmitted» the MCS 
receives CUSTIN12345 YES. The MCS first checks for a trancode and 
determines that this message is to be sent to the program GEMCOSPACK/ 
GEMCOS/SAMPLE because the trancode is CUSTINe The MCS then foragats 

the message using the format IN since the DEVICE section associates the 
format IN with the formatrID CUSTIN. After formatting with format IN» 
the message is CUSTINO123451. This message is then sent to the 
Application Programe 


[CUSTIN] 


CUSTOMER ACCOUNT NUMBER 
RECEIVABLE AGING INFO? 


Figure 676. Example Filled-In 
Input Form 


SECTION 7 


SYSTEM OPERATION 


COMPILING WITH MCSTCL. 
For instructions relating to the execution of the TCL compilers refer 
to <deck descrtiption> under TRANSACTION CONTROL LANGUAGE tn section 3. 


EXECUTING _ AN _MCSe 
Before executing the MCS» the MCSTIC file must be on disk CMCSTIC was 
created oy the TCL compiler). To initiate the MCS» enter: 


EX MCSSRC/SOURCE 


If a <OBJECT CODE FILE NAME statenent> was present in the <GLOBAL 
section> of the source YCLep enter: 


FX <file-I0> 
The use of a <FILE statement> following the execute command in an 
attempt to rename MCSQUEUE ts not successful. The MCS always opens 
always opens the remote file whose name was given in the <QUEVE NAME 
The default value of QUEUE NAME 1s MCSQUEUE. 


When an CS ts run under a systema software released prior to 5.1 or 

when the "C" entry of the name table is blank» a Network Controlter aust 
be executed if one is not already running. If a system software 

release of 6.21 or tater is used ard there is a nonblank *C* entry 

in the name table» the Network Controtler ts automatically executed by 
the system. (For a description of the system name table entries» refer 
to 8 1800/B 1700 Systems Software Operational Guides forma 1068731.) 


Once the GEMCOS MCS beginss the user*s application programs and any 
subordinate MCS programs may be started. 


A Network Control Command may be presented to the MCS at any time by 
entering an ACCEPT directly to the MCS. For examples the folloning 
message entered at the supervisory console makes STATIONA not 

ready. 


<m~n>AX*CSR STATIONA N 
The <m-n> is the mix number of the MCS and the asterisk (*) is the sig- 
nal character. No spaces between AX and the signat character are 


permitted. 


To enter Network Control Commands from a card readers the operator 
should ready a card reader with a deck tabeled MCSOLICRD and enter: 


<mon>AXCARDS 


The MCSOLICRD deck should contain one Network Control Command per card. 
The signal character must be in card cotumn one. 


RECOVERY PROCEDURE. 
A GEMCOS MCS which has auditing togitc writes audit records into a disk 
file. This disk audit file ts closed: 


ae When it becomes filled. 
be At Endwof~-Job. 


A new audit file is created after the previous one is filled. 


The audit fite-ID is MCSAUDIT/AUDITInnn»> where <nnn> is a number in the 
range 0 thru 999 and is incremented for each new audit file. 


When the MCS needs an audit file for recovery Cother than the audit 
file it is currently creating) and that file is not currentiy on disk» 
it displays the following message on the Control station or console 
printer: 


FILE MISSING ~- MCSAUDIT/AUDIInan 


While the MCS waits for the backup audit file» it continues to service 
the network. The operator inforas the MCS that the requested backup 
audit file is available by entering the ADK Network Control Command at 
the console keyboard. 


During recovery» the MCS continues to process messages for programs 
that are not recovered. If the MCS receives a message which is 
destined for a program that is being recovered» it sends a message to 
the originating station indicating that recovery is in progress and 
that the input message was ignored. 


SECTION 8 


AUXILIARY PROGRAMS 


MCSSIMe 

The program MCSSIM makes it possible to test a GEMCOS MCS» inctuding 
user MESS codes without the presence of a Network Controller or a 
remote network. Inputs are simulated via a card reader and outputs 
are Listed on a line printer. 


The MCS runs in simulation mode when the <SIMULATION statement> speci- 
fies a vatue of TRUE. In simulation modes the MCS changes the device 
type of MCSQUEVE from a remote fite to a queue file. Hence» input mes- 
sage traffic no Longer comes from the network but from any oprogran 
writing into a queue file Labeled MCSQUEUE.j/ MCSSIM is such a program. 
The source to MCSSIN is MCSIMS. 


MCSSIM expects a card file Labelled MCSSIMCRD. The format of MCSSI4YCRD 
is closely retated to the 8 1800/B 1700 MCS/Network Controiter inter- 
face. The MCS/NC interface consists of a series of message types» each 
having an explicit function. For a definition of these message types» 
refer to Burroughs 8B 1700 Systems Network Definition Language Reference 
Manuals form 1073715. The user shoutid be familiar with the MCS/Network 
Controller interface before attempting to use a GEMCOS MCS in sinulation 
modes 


NCSSIM reads cards in a format defined by the MCS/Network ControlLlter 
interface buttiding a record to be sent to the MCS. The information for 
each record to be sent to the MCS must be punched beginning in card 
column 1» extending to colusan 80.5 and onto succeeding cards if neces- 
sary. Column positions of the cards correspond directly to byte 
positions of the message types. MCSSIM is able to determine how nany 
cards are required» concatenating the card images into the record toa be 
piaced into MCSQUEUE. For examples if a station-status reply was to be 
sent to the MCS» one card would be punched with 80 charaztters of infor- 
mation. <A second card would be required for the remaining 35 charac= 
ters (a station=status reply is always 116 characters tong). If a 
message from a program with a text size of 150 characters were to be 
Simulated» three cards would be required. The first card would have 
the appropriate 50-character message header (with the text-size field 
set to 150) and the first 30 characters of text. The sezond card wouid 
contain the next 80 characters of text. The third card would have the 
remaining 40 characters. 


One exception exists to the above MCSSIMCRD card format rule. For data 
message types» the error fieids corresponding to card columns 24 and 
25» represents 16 bits of informations not two characters of informa- 
tion. The two card columns cannot be used to express all possibie 
combinations of 16 bits. Therefores card columns 24 and 25 remain 
blank. The information to be placed inthe error field of the record 
is expressed in the filler fields columns 45 thru 50» as a decimal nua- 
ber representing the desired bit configuration. MCSSIM sonverts the 
information in the filler field to a bit string» places the results 


MCSSIM 


into the error field and blanks out the filler field. To simulate a 
time-out conditions for example» the value 004096 would de punched into 
the filler field. 


If MCSSIM is to stimulate messages from a program to the MCS» and that 
program is using an tnterface of PARTICIPATIONs the Common-ar2a header 
must be present. For examples» suppose that a 10-character message is 
simulated from a program whose COMMONSIZE is 69. Two cards are 
required. The first card would have a MCS/Network Controller header 

in colugans 1 thru 50. Columns 51 thru 80 would contain the first 30 
bytes of the Commonwrarea header. Columns 1 through 30 for the second 
card would hotd the remaining 30 bytes of Commonvwarea information. The 
10 characters of text would follow in columns 31 through 40. 


Whether or not the MCS ts operating in the SIMULATION modes» it must 
perform its initialization routinese In order to initialize correctly» 
the MCS must receive information about the network it is to control or 
simulate. During initialization» the MCS expects as the first record 
in MCSQUEVE» a remote file information reply Cmessage type-29). 


NOTE 
In normal modes the MCS receives this 
reply from the Network Controller by 
issuing a remote file information 
request. From the remote file informa- 
tion reply» the MCS identifies the app- 
ropriate Logical Station Numbers. The 
MCS expects a station status response 
Cmessage type 721) for each station in 
its remote file. Here agains in normal 
modes the MCS receives these replies 
from the Logic Network Controller by 
Tssuing station status requests. From 
the station status replies» the MCS is 
abie to associate Logical Station Numbers 
With station names. 


After the initialization process» the MCS may go through the network 
restoratton procedure. If this ts the case» Network Controtler change 
responses (message type 23) may be expected by the MCS. During the 
initialization orocesss» only change responses and FILE OPEN requests 
are recognized by the MCS. 


Once the MCS ends initialization Cor network restoration)» tha MCS 
enters its normat message processing modee Any message can be sent to 
the MCS for testing purposes. However» care must be tak2n when the 
message sent to the MCS causes the MCS to expect a Network Controller 
response. For examples» a valid Change Station Ready command («CSR ln) 
input to the MCS causes the MCS to tssue a change request (message 
type“22) which must be answered by a Network Controller Zhang2 Response 
messagee Somewhere in the MCSSIMCRD deck following the CSR commands 
there should be a Network Controller change response to the MCS change 
request. For ease of uses the MCS should not be caused to 3ssue changes 
recall or remove requestse 


8-2 


neste 
EXAMPLE SIMULATION CARD DECK. 


In this example Csee figure 87-1) a network with one station» LSNOL»s is 
simulated. The first card of MCSSIMCRD is a remote file information 
reply specifying that there is one station tin the remote file. The 
second and third cards are a station status reply describing LSNO1 as 
being ready» enableds having a retry count of 255» etc. The fourth 
card simulates a report program status command from LSNOL. Cards five 
and six simutate a FILE OPEN request by a program named PGMA. A mes~ 
sage from PGMA to LSNOL ts simulated with card seven. 


NOTE 
PGMA has included a Common~area header 
of 60 bytes. 


2DATA MCSSIMCRD 
290000000000000000100000000001 001000 
Z1001L0001LSNi 11344022500 020207 07 


255000000000 100000000000 00 0000000000 3 
01000100040010000000000 00000000000000000 44C000C0zSRPS 


103000000000000000000000 PGMA 0 00002 OOLCRAT1 


001 
O0CO0L0068002Z000C000000 00000000000 000000 4400000000010 co08 
HI THERE 
PEND 


Figure 8-1. Example Simulation 
Card Deck 


MCSFIX. 

MCSFIX provides the patching capabilities of the UPL compiler. Thus a 
sourcecode file may be patched» listed and/or sequenced without having 
to be compiled. In particular» this program is intended for use with 
MCSGTS» should it be necessary to release a patch notice. 


The file names used by MCSFIX correspond to those of the UPL compiter: 
ae Disk input source file is Labeled SOURCE. 


be Oisk output source file is Labeled NEWSOURCE. 
ce Card input patch file is tapeted CARDS. 


MCSFIX 
cont 


MCSFIX always expects the input card file and creates the output disk 
file Calthough the disk file may be closed with purge). Records in 
CARDS fali into one of two categories: controt cards and patch cards. 
Control cards» identified by a dollar sign ($3) in column ones specify 
MCSFIX options. Patch cards and cards without a dotlar sign in columnn 
1 are used to create new tines of source or to replace existing lines. 


Columns 73 through 80 are reserved for optional sequence numbars. When 
sequence numbers exist tn either of the two input files» they should be 
In ascending orders otherwise» an error is reported. Howevers when an 
error is detected» the run is not aborted even though results are 
unpredictable (but possibly of value). 


The following is a list of available options and their actions: 


Qption Action 


LIsT This option creates a Listing of the output 
disk filee If a sequence number is specified 
in columns 73 through 80» the List starts at 
that number ors if it does not exists at the 
next highest number. By defauits» LIST is.set. 


MERGE When this option is set» MCSFIX expects the 
file tabeled SOURCE» merges records from the 
file CARDS and creates the output file Crefer 
to option to save the output file). <A record 
from CARDS replaces a record in SOURCE when 
both have the same sequence number. A record 
from CARDS ts inserted when there is no record 
in SOURCE with a matching sequenze nunber. 

C€To delete records in SOURCE» refer to VOID 
option.) When MERGE is not sets» an input disk 
file is not expected» and the output disk file 
is created directly from the input card file. 
The control card specifying MERGc must precede 
any patch cards and may not be resete By 
default» the MERGE option is off. 
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MCSFIX 
cont 


Qption Action 


NO 


This option causes the output disk file to be 
saved (closed with lock). The control card 
with NEW specified must precede any patch cards 
and may not be resete By defauits th2 NEW 
option is off. 


This option turns off or reverses the effect of 
any options which follow it on the same control 
carde This is different than the UPL corpiler 

Cin which NO applies onty to the option immed- 

jately following it). 


SEQ <sssssSS5> This option causes sequence numbers starting 


+ III! 


with ssssssss and incrementing by IIII to be 
applied to the output disk file Cand printer 
Listing if LIST ts set)- [111 may not exceed 
9999. NO SEQ terminates any sequencing 

taking place. Sequence numbers of records in 
CARDS are always relative to the oid sequence 
numbers ia SOURCE regardless of whether or not 
the sequencing of the output disk file is 
specified. 


VOID <nnnnnnnn> The VOID option causes records from SOURCE not 


to be included in NEWSOURCE Ciee.» it deletes 
them). <nnnannnn> must be present in columns 
73 through 80. If <mmammmmm> is not present» 
the record in the input disk fiie with the 
sequence number <nnnnannnan> is voidede When 
<mmmameame> is present in columns 7 through 1%» 
all records with sequence numbers <nnnnnnann> 
through <aammmmamm>s» inclusive» are voided. 


To execute MCSFIX» the foliowitng control cards are used: 


ae 
be 
Ce 
d. 
Ce 
f. 


? EXECUTE MCSFIX 

? FILE SOURCE NAME <input-filerident ifier>> 

2? FILE NEWSGURCE NAME <output-file~identifier>>; 
2? DATA CARDS 

Ccontroi and patch cards) 

2? END 


MCSRECALL 


MCSRECALL» 
In the Global section of the Transaction Control Language (CTCL)» the 


user is given the option of defining a Message Recaltdi Program to recaltt 
any message inserted into an audit file. There are two ways to retrieve 
messages from the audit files by simply recalling the tast <n> messages 
or by recatling messages by time of day. Oniy one program needs to be 
declared to the TCL compiler. The trancode(€s) used must be dectared 
within the Program section of the Recali Program. The Global section 
statement necessary to declare a Recall Program foltows. 


RECALLPROGRAM = <identifier>. 


The following rules must be adhered to when defining the attributes 
of a Recall Progr an. 


ae The program must be declared as a User Progran. 


b. The COMMONSI7E statement must be absent or set to a value 
of 60 (default value). 


ce The program must not use the auditing capability. 


Inctuded on the GEMCOS release tape is a fully functional message 
Recall Object Program called MCSRECALL. The user need only declare 
this prograa to TCL. 


Prior to initiaily executing the supplied Recall Program» the user must 
make the following modifications: 


ae The extarnal file name associated with the MCSTIC file must be 
the same as that associated with the MCSTIC file of the MCS. 


b. The external file name of the MCSREM remote file must be a 
remote file of the Network Controller. Also» the Number of 
Stations (NST) attribute must be set to the number of stations 
requested by the remote file. 


See Appendix E— for a summary of all files contained in MO SRECALL. 


MCSRECALL 


cont 


The syntax of a recall message Cas expected by MCSRECALL) ats as follows: 


<recall message> 


<recall primitive> 


<time recall tlist> 


<last recall list> 


<recali source> 


<time of day range> 


<date specif ication> 


<message type> 


{declared trancode from ITCLI 
<period> 

<recall primitive> 

<period> 


TIME <slash> <time recatl tList> / 
LAST <stash> <Last recaii tist> 


<recall source> 

<time of day range> 
<date specification> 
<message type> 
<message destinati on> 


<recall source> 
<integer> 

<message type> 
<message destination> 


C<station number>) <stash> / 
<station mnemonic> <stash> / 
<empty> 


<time of day> <dash> <time of day> / 
<time of day> 


<slash> ON <date> / 2ampty 


<slash> <message type identifier> / 
<emoty> 


B-7T 


MCSRECALL 


cont 


<message destination> $3= <slash> PRINTER / empty 

<station number> £23= <integer> 

<station mnemonic> 23= <identifier> 

<time of day> 33= L4-digit time of day ranging from 


0000 to 2400] 
<date> 33= <month> <stash> <day> <slash> <year> 


<message type identifier> <2:= [INPUT / IN 7 
BUTPUT / OUT 7 


10 
<month> 33= {Linteger ranging from i to 12] 
<day> 23:= Linteger ranging from i to 31] 
<year> ss= [2-digit integer spe:ifying year] 


If <recali source> is empty» then the recalled messages are for the 
station entertng the requests otherwises they are for the station nane 
or number requestede 


If <message type identifier> is INPUT» only the specified input aessages 
are recalieds if OUTPUT» only the specified output messages are recalleds 
if I[70» then both the input and the corresponding outodut messages are 
recalled. If <message type identifier> 1s empty» ondiy output messages 
are recalled. 


The recall message by timerof-day allows the user to sperify a tine 

range in which to indicate the messages to be recalled. If a date its also 
specified» the messages for that date are recatied tf the corresponding 
audit fate or files are on diske 


If LAST is specified» the last <n> messages requested are recatled. If 
there are fewer than <n> messages to recalls» then the number of messages 
found is recalied. 


If PRINTER &@s selected from <message destination>» then all the recattled 
messages are sent to the system printer instead of to the requesting 
station. 


Examples: CIRC is the user's TCL~defined trancode for the Recall Program) 


IRC.TIME/1209. 


IRC.jTIME/120071215/10. 


IRC.TIME/0300-15900/0N 
03/31/79 /IOD/PRINTER. 


IRC.TIME/€ 3)9/0900-0930 
/SINPUT. 


IRC. TIME/LSN2/1000- 
1O045/0N 04/12/79 / 
IO/PRINTER. 


IRC.LAST/10. 


IRCeLAST/€2)/5/10. 


IRC.LAST/50/ PRINTER. 


IRC.LAST/LSN3/100/ 
ID/PRINTER. 


nN HN nN rm 


i 


MCSRECALL 


cont 


Recall the output messages stamped with 
time 1200 for this station. 


Recall both the tnput and output messages 
between 1200 and 1215 for thas section. 


Recail both the input and output messages 
between 8 AM and & PM on March 31» 1979 
and send them to the system printer. 


Recatt the input messages initiated at 
station 3 between 9 AM and 9:30 AM and 
send them to the requesting station. 


Recalt both the input and output messages 
from station LSN2 between 10 AM and 10:45 
AM on April 12» 1979 and send thea to the 
system printer. 


Recalt the last 10 output messages for 
this station. 


Recaiit the last 5 input messages and 
associated output messages from station 2 
and send them to the requesting station. 


Recalt the last 50 output messages for 
this station and send them to the systen 
printere 


Recait the Last 100 tnput messages and 
assoctated output messages from station 
LSN3 and send them to the system printer. 


SECTION 9 


RECOVERY 


GENERAL} 

8 1800/B 1700 Series GEMCOS provides a broad range of resovery capa- 
bilities within the TCL. This gives the user the abitity to analyze 
apptlication-oriented needs and to select the recovery options required. 


In this manual» recovery means that a fattlure has occurrads thereby 
interrupting the ability to conttriue normal transaction processing 
until some corrective action is taken. The recovery process is 
considered to be the recrestablishrent of normal processing. 


Throughout this sections assume that the user wants to mi némize 
exposure to situations wherein ftle and/or data base retoads are 
required following a fatlure. In such situationss the online user 
network normally remains in a nonproductive state while reprocessing 
takes place for all transactions that have occurred since the time the 
data base was last dumped to some form of backup storage. fTh2 tine 
loss due to this nonproductive state can be costly to the user and 

is based directly upon several factors. The main factors follow: 


ae Data base size. 

be Length of time stnce last data base dump. 

ce Transaction volumes since last data base dump. 
de. fTransaction-throughput activity. 


Further» assume that the user desires to free user programmers from 
recovery concerns as much as is possible» since recovery solutions are 
extremely complex for an integrated» batch/on-line system where a data 
base is being updated in a multitprogramming environment. 


The goat of B 1800/8 1700 Sertes SEMCOS 1s to make the recovery process 
presents yet virtually invistble»s» to application programs. In return» 
the user is expected to follow several straightforward prograaming con- 
ventions for normal processinge These conventions vary stightly» 
depending upon the Level of recovery desired. 


Although the MCS ts *"tgnorant” of any data managernent system and con- 
tains no data management code embedded within it» the recovery mechanism 
fully accommodates OMS II (Burroughs Data Management System-Version I[1). 
The recovery mechanism works with any data management system as long as 
the programming conventions discussed in this chapter are followed. 


NO RECOVERY. 

Among the recovery options availaole to the user is the specification 
that no recovery be applied to a "failed*™ program or data base. This 
option is the default option for every program declared in TCL. It may 
also be specified in the Program section with the fotlowitng TCL syntax: 


RECOVERY = NONE. 


When the system or the program fails» no attempt is made to r2process 
any messages that may have been lost at the time of failure. This is 
true whether or not the MCS ts auditing messages for that prograrn. 


TYPES_OF RECOVERY. 

The Lowest Level of recovery» queue restorations is for programs which 
do not share a data base with any other program. Queue restoration 
places the reponsibility for determining 1f recovery is required on 
the user application program. The user application program must also 
direct the MCS to begin recovery with a certain specified message. 
When the MCS receives a request from a program for queue restorations 
it resends all succeeding audited messages to that prograam. 


The next tevet of recovery» data base recovery» is for Application Pro- 
grams which share a data base with other programs. The only recovery 
responsibility placed on the User Program 3s to save certain infor- 
mation from the MCS~-supplied header in a place where it can b2 accessed 
by the Restart Program (defined Later in this section).j In DMS II pro- 
grams» this as normality the restart data set. The other recovery 
requirement for such a User Program is that the program must notify the 
MCS when a DMS JI abort occurs. UWhen the MCS determines that recovery 
is needed Cat BOJ» because a program has failed or because a program 
notified the MCS that a DMS II abort occurred)» the MCS executes the 
Restart Program. After ail messages are received from the Restart Pro- 
grams the MCS begins recovery of each program in the data base that 
requires it. The order of recovery is oldest message first. 


The most sophisticated form of recovery» synchronized re:overys is 
similar to data base recovery. In this type of recoverys the MCS 
recovers each message in the order tt updated the data base when the 
message was originally processed.j To accomplish this» the MCS assigns 
a Data Base Sequence Number (DBSN) to each output message froa the proa- 
gram. When recovery is required» the order of message recovery is in 
DBSN order rather than oldest input message first. Also» during syn- 
chronized recovery» the MCS performs an output message analysis to 
minimize duplicate output messages at the station. 


QUEVE RESTORATION RECOVERY. 

When a user application program receives a transaction from the MCS in 
the course of normal processings tt should check the MCS-INPUT"ADDR 
fieid in the Commonwarea header. If this field is nonzero and this 
program may later need to be recovereds the data in the MCS~INPUT-ADDR 
field must be saved.j When recovery its requireds the user must return 
the data in the MCSINPUT“ADDR field to the MCS. If the MCS~INPUT<-ADDR 
fieitd is zero» the transaction was not audited and the user application 
program should ensure that this transaction does not cause any updates 
unless this program does not use recovery. 


The MCS performs queue restoration for programs which have a "RECOVERY 
= QUEUERESTORATION.” statement in the Program section of TCL. This 
recovery is initiated when the user application program sends a message 
to the MCS with the Common~marea header field MCS-TYPE set to 20. Also»s 
this program should set the Common~-area header field MCS-INPUT“ADDR to 
the value it contained in the last completed transaction. This value 
would have been saved as previously described in the course of normal 
processinge The user application program should then ignore ail trans- 
actions from the MCS until it receives a message with MCS“TYPE set to 
21. Next» the user application program should send a message to the 
MCS with MCS“TYPE set to 22. This "handshaking™ process ensures that 
no extraneous messages are processed Dy the programe Finality» the MCS 
passes all the recovered transactions back to the application prograam 
and normal transactions can again be sent as they are rezetved. The 
Application Program can determine when recovery is complete by checking 
the MCS“RECOVERY“STATUS field tn the Common-area header. A value of 
zero indicates that this message is a normal message. 


When more than one program needs queue restoration concurrently» the 

MCS passes the messages to the programs in the order they were placed on 
the audit file in one pass of the audit file. The MCS makes no attenodt 
to reproduce the exact sequence of transactions and/or data base updates 
which occurred during normat processinge 


During queue restorations the MCS does not perforn any output message 
anatlysise The MCS passes ati recovered output received froa the 
Application Programs to the stations. 


NONSYNCHRONIZED AND SYNCHRONEZED DATA BASE RECOVERY. 

The following discusston assumes a basic knowledge of the B 1800/ 

8 1700 Systems Data Management System II (DMS II) Reference Manual» 
form number 1089794. Programs that were dectared in the Program section 
of TCL with a DATABASENAME statersent fatl into one of two categories. 
The first category consists of programs that were deciared with the TCL 
Statement “RECOVERY = DATABASE.”. This is nonsynchronizead data base 
recovery and henceforth shall simoly be cailed data base recovery. fhe 
second category consists of programs that were declared with the TCL 
Statement “RECOVERY = SYNCHRONIZED". This is synchronized data base 
recovery and henceforth shall be calted synchronized recovery. 


REMOTE FILE OPENS. 

When a data base or synchronized recovery program opens its remote 

files the first message sent to it has the Common-area header field 4CS- 
TYPE set to a value of 23. The first three bytes of the message text 
area contain the program numbers the next three bytes contain the muiti- 
copy number» and the next twelve bytes contain the date/time stamp. In 
user application programs using DMS {I» this information must be saved 
to place in the restart data sete. See figure 9-1 for a recomsended data 
set definitions and figure 9-2 for a remote file record definition. 


RESTARTAREA RESTART DATA SET ( 
GEMCOS"LITERAL ALPHA (6)> 
GEMCOS-PGM-NBR NUMBER (3)>5 
GEMCOS-MULTI“NBR NUMBER (3)> 
GEMCOS“DATE~TIME NUMBER (12 D> 
GEMCOS“-DATA NUMBER (€9)) 
¥ 
POPULATION = 1090; 
z 
RESTARTSET ORDERED SET OF RESTARTAREA 
KEY IS ¢ 
GEMCOS~LITERAL » 
GEMCOS~DATE~TIME> 
GEMCOS~PGM-NBR» 
GEMCOS“MULTI-“NBR)>» 


Figure 9-1. Recosanmended DMS Ii Restart 
Data Set Definition 


O1 GEMCOS“REMOTE“FILE-RECORD. 
05 GEMCOS“COMMONAREA~HEADER. 


10 MCS-LSN PIC 9(€4). 

10 FILLER PIC 9. 

10 MCS~“SEQ-ND PIC 9(€6). 

10 MCS*NDOL~TIME PIC 9(7). 

10 MCS“TEXT<SIZE PIC 9C4). 

10 MCS-TERM<-TYPE PIC 9(€2). 

10 MCS-MSG-ID PIC XC6). 

10 MCSINDEX-1 PIC 9(2). 

10 MCS~INDEX<2 PIC 9(€2). 

10 MCSF MT-ERR PIC 9(2). 

10 MCS“TYPE PIC 9(€2). 

10 MCS~“INPUT-ADDR PIC 9(9). 

10 MCS-RETRY~COUNT PIC 9. 

10) MCS“RECOVERY<STATUS PIC 9. 

10 MCS“OUTPUT~ADDR PIC 9(9). 

10 FILLER PIC 9(2). 

10 WMCS“USER“AREA PIC XCN1). (#5) 
05 MCS~TEXT PIC X€CN2). (C#6) 
05 MCS*TYPE*23~MESSAGE REDEFINES MCS-TEXT. 

10 GEMCOS“HEADER=PGM-NBR PIC 9(3). 


10 GEMCOS“HEADER“MULTI-NBR PIC 9(€3). 
10 GEMCOS“HEADER“DATE“TIME PIC 9(€12). 
10 FILLER PIC X€N3). (C7) 


Figure 9-2. Recommended Remote File 
Record Definition 


5 Ni is the length of the user portion of the common area headers if 
there ts no user portions then MCS-USER“AREA should not be specified. 


6 N2 1s the length of the user's texte 


7 N3 318s N2 mtnus 18. 


Upon receipt of this messages the foliowing COBOL code should be executed 
in the DMS II user application program: 


MODIFY RESTARTISET AT 


GEMCOS“LITERAL = “"GEMCOS" AND 
GEMCOS“DATE-TIME = GEMCOS“HEADER~DATE-TIME AND 
GEMCOS~PGM-NBR = GEMCOS"HEADE R“PGM-NBR AND 
GEMCOS“MULTI“NBR = GEMCOS"HEADER~MULTI-NBR 


ON EXCEPTION 
CREATE RESTARTAREA 
MOVE “GEMCOS"” TO GEMCOS*LITERAL 
MOVE GEMCOS“HEADER“DATE~TIME T0 GEMCOS~“DATFE~TIME 
MOVE GEMCOS“HEADER-PGM-NBR TO GEMCOS“PGM “NBR 
MOVE GEMCOS~HEADER@MULTI-NBR TO GEMCOS“MUL TI-NBR 
MOVE 0 TO GEMCDS-DATA. 


TRANSACTION PROCESSING. 

A transaction is any message tn which the MCS-TYPE is set to the value 
zeroe A OMS II application program must do two things in addition to 
processing each tnput transaction. First» it checks the MCS“INPUT“ADDR 
field of the Commoncrarea header. If the field is zero» the prograa 
should not do any updates to the data bases as this transaction has not 
been audited and will» therefores not be recovered.j Seconds if the MCS- 
INPUT-ADDR field is nonzero»s it must be saved in the restart data set 
Ci.e@e.2 “MOVE MCS“INPUT“ADDR TO GEMCOS“DATA.*). If MCS“TYPE is set to 
zeros updates to the restart data set are permitted. 


Output messages are then sent to the MCS according to the following: 
ae MCS~“TYPE should be set to zero on the last message. 
be MCS“TYPE should be set to one on any intermediate transactions. 


A minimum of one output message must be sent to the MCS for each 
audited input transaction. 


END-OF-J908. 

The user application programs should be prepared for the receipt of a 
message from the MCS wath MCS~“TYPE set to 24. This message instructs 
the program to close the data basee If the data base close is success=- 
ful» the program should send the MCS a response message having MCS“TYPE 
set to 25. fhe MCS then sends an Endrof-Fite CEOF) indi: ator» and the 
program should go to End-of-Job CE0J). If a program abort ts detected 
when the data base is closed» the program shouid send the MCS a sessage 
with MCS“TYPE set to 20. If an Application Program closes its remote 
file and/or goes to ENJ at any other time» the MCS considers the program 
to be aborted. Application programs may not delete the restart data 
set record before proceeding to End-of-Job. 


PROGRAM ABORT. 

When an Application Program associated with a data base aborts (i-.ee» 
closes its remote fide before receiving an EOF or is DSei)» the MCS 
marks that program disabled and stops accepting messages from stations 
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for any program using that data base.ew When an operator or the network 
administrator enables the program Cusing the CLE Network Control Command) 
from the Control station or the consoles after taking any corrective 
actions the MCS executes the Restart Program. After the Restart Program 
sends the MCS the necessary recovery informations the aborted prograa 

is rewexecuted by the MCS. Att transactions not reflected on the data 
base are resent to the program they were originally sent toe The “CS 
then returns to normal processing. 


RECOVERY PROCESSING. 

When a user apptication program detects a DMS II aborts it should send 

the MCS a message with MCS~“TYPE set to 20.2 The program should then ignore 
ail messages from the MCS until it receives a message with MCS-TYPE set 

to 21. When a user application program receives a message with MCS- 

TYPE set to 21 (whether or not it has sent a type "20 message)» it 

Should execute the following coding sequence: 


BEGIN“TRANSACTION NO-“AUDIT RESTARTAREA 
ON EXCEPTION 
<exception handling code> . 
END“TRANSACTION NO“AUDIT RESTARTAREA 
ON EXCEPTION 
<exception handling code> . 


This code sequence clears the DMS II abort flag prior to the initiation 
of recovery. An ABORT exception at BEGIN TRANSACTION or END 
TRANSACTIONs can be itgnoreds processing does continue. ;inallys» the 
program should send a message to the MCS with MCS“TYPE sat to the value 
22-e The MCS then sends the program the transactions that wer? 

rolled back from the data base. When recovery is finishads the MCS 
begins sending normal transactions as they are received. The 
application program can determine when recovery is complete by checking 
the MCS“RECOVERY“STATUS field in the common area header. A value of 
zero indicates that this message 1s a normal message. 


RECOVERY AFTER SYSTEM FAILURE. 

If a MCS terminates abnormatly Ci-eee» a DS or DP condition arises or 

a HLT KILL was done) or the MCP fasts and a Clear/Start is necessary» 

the MCS» when remexecuted» executes the Restart Program and checks the 
audit file to determine if any transactions are not reflected in the 

data base.w If there are transactions that are not reflezted in the 

data base» the trancodes'" progras or programs are automatically executed 
by the MCS. ALL unprocessed transactions are sent to the corresponding 
programs. Normal processing begins when all recovered messages are sente 


DATA BASE RECOVERY CNONSYNCHRONIZED). 

Data base recovery performs a queue restoration on all Application Pro- 
grams in the data base needing recovery. Data base recovery does nat 
attempt to duplicate the order of updates to the data base or to per- 
form any output analysis. The only difference between data base 
recovery and queue restoration after the initialization is that data 
base recovery does not allow messages to be entered from stations for 
any program using the data base until atl programs using the data base 
have finished recovery. 
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SYNCHRONIZED RECOVERY. 

This form of recovery was defined earlier in this section under Types of 
Recovery. OMS II rolls back a data base in time to remove logical data 
base updates that were partitiatiy completed at fasture time. (CA 

single logical update transaction normally results tn multiple data 

base updates).j During recovery» the MCS performs an audit trail analy- 
sis relative to the rotied-back data base state» so that input trans~ 
actions which were removed from the data base are "recycied™ for 
application processinge Input transactions which have been successfully 
audited by the MCS prior to failures but which have not yet raached the 
point where they are passed to an aoplication program for processing 

are requeued. Transactions falting into the “"recycte"™ category 

can be reprocessed so that the identical update sequence to the data 
base is maintained. 


The MCS does not just hand to 2ach program its particular transactions 
in the same sequence that the programs received them prior to failure. 
Rather» the MCS attacks the more complex problem of reestablishing the 
exact sequence of events that oecurred on the data basee This recovery 
technique considers the fact that some variable number of independent 
program executions could be receiving transactions concurrently» and 
thus» each transaction could result in multipte concurrent updates to 
the data base. This feature becomes extremely important when multiple 
transactions which resutt in access to common data are asynchronously 
flowing through the system at the same time. Synchronized recovery 
allows failures to occur without Application Programs and terninal 
operators needing to have any knowledge of theme At the same tines 
data bases tan be maintained which are in total agreement with any 
messages delivered to the network prior to the tine of failur2. Addition- 
ally» an analysis of input transactions recycled due to a data base 
rollback is performed by the MCS on application-generated output to 
eliminate duplicate transmissions. fo accomplish this» the MCS directs 
the Network Controller to return a “good results™ reply when a primary 
output message ts received at the station. 


The MCS ensures that a successful» totally synchronized recovery has 
occured. Yet» under certain circumstances» the MCS may Lose output 
messages or send duplicate output messages to stations. Extraneous up" 
dates to the data bases the most critical cases» do not occur. If 
output messages are Lost» the MCS notifies the terminal operator of the 
extent of that toss. If dupltcate output messages are sents the MCS 
informs the terminal operator that a list of possible duplicate messages 
follows. After sending these messages» the MCS informs the terminal 
operator that the possibly duplicate messages are finished. In doth 
casese the number of messages Lost or duplicated is usually quite smalt. 
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Meo FP Rigg. 


RECOVERY“RELATED CONVENTIONS. 
The conventions which must be fotlowed by the user to ensure a synch- 
ronized recovery are detailed tin the foltowing paragraphs. 


CONVENTIONS FOR A *"RECOVERY = SYNCHRONIZED™ SPECIFICATION. 


ae 


Ce 


de 


A User Program must claim transaction-related resources prior 
to updating any of them. Thus» alt necessary data management 
records should be tocked before entering the transaction state. 
In many situationse this might entail merely locking a parti- 
cular node within a data hierarchy. 


A User Program must not unlock any transaction resources until 


the transaction is complete. 


Thus» the DMS II 2c ND“TRANSACTION 


can be altowed to untiock data management records. 


A User Program must send messages to stations azcording to the 
following protocol: 


1) 


"Secondary outputs” are sent firste These are outputs 
which are passed to the MCS with the MCS-TYPE field of the 
Common-area header set to le the value 1 signifies to the 
MCS that the User Program 1s not done with the current 
transaction and wishes to send more output. 


The last output generated during normal prozessing by a 
User Program as a result of receiving a given input trans- 
action is termed the “primary output". The primary output 
of a transaction 1s a message sent by the User Program 
With a value of 9 in the MCS“TYPE field of the Common-areaa 
header. The vatue 0 signifies to the MCS that the User 
Program is finished with the current transastion. The MCS 
assigns the Data Base Sequence Number CDBSN) at this time. 
The priaary output may be delivered to a station other 
than the originating station» or it may have a text Length 
of zeroe In the latter case» no output message is detiv- 
ered to the station and the MCS audits an output message of 
zero Length. 


A User Program must cause the DMS II restart information to 
be forwarded to the DMS II audit trail when Leaving trans- 
action state» as opposed to when entering transaction state. 


The proper sequence of events for a User Program which has synchronized 
recovery is outlined in the following basic Logic flow example. 


Example: 
INITIALIZE. 
OPEN DATABASE. 
READ MCSQUEUE AT END STOP RUN. 
IF MCS“TYPE NOT = 23 £STOP RUN. 
MODIFY RESTARTSET AT 
GEMCOS“LITERAL = "GEMCOS"* AND 
GEMCOS“DATE-TIME = GEMCOS“HEADER-DATE-TIME AND 
GE MCOS-PGM-NBR = GEMCOS-HEADER-PGN-NBR AND 
GEMCOS“MULTI“NBR = GEMCOS-HEADER-MULTI-NBR 
ON EXCEPTION 
CREATE RESTARTAREA 
MOVE "GEMCOS* TO GEMCOS<LITERAL 
MOVE GEMCOS“HEADER-DATE-TIME TO GEMCOS“DATE“TIME 
MOVE GEMCOS“HEADER-PGH-NBR TO GEMCOS-PGN-NBR 
MOVE GEMCOS“HEADER-MULTI“NBR TO GEMCOS-MUL TI-NBR 
MDVE 0 TO GEMCOS<DAT A. 
PERFORM PROCESS THRU PROCESS-EXIT UNTIL EOF = 1. 
STOP RUN. 
PROCESS. 


READ MCSQUEUE AT END MOVE 1 TO EOF 
GO TO PROCESS~EXIT. 
IF MCS~“TYPE = 24 
<SEND "TYPE 25" MESSAGE> 
GO TO PRONCESS~EXIT. 
IF MCS“TYPE = 21 
<PROCESS & SEND “TYPE 22" MESSAGE> 
GO 19 PROCESS~EXIT. 
<LOCK DATA BASE RECORDS TO BE UPDATED> 
BEGIN“TRANSACTION NO~AUDIT RESTARTAREA. 
<MOVE RESTART INFORMATION TO RESTART AREA> 
* 
*& 
* 
<UPDATE DATA BASE> 
<SEND SECONDARY OUTPUTS> 
END“TRANSACTION AUDIT RESTARTAREA. 
<SEND PRIMARY QUTPUT> 
PROCESS~EXIT. 
EXIT. 


RESTART PROGRAM. 

Every system of programs (data base) that has synchronized recovery 
must have a Restart Program defined. The Restart Program is defined 
in the Program section of TCL iike other User Programs with the 
following special syntax: 


RESTARTPROGRAM = TRUE. 
Only one Restart Program may be defined for a system. 


When DMS I1 roils back a data base» the Restart Program is ex2cuted 

by the MCS as the first step in its synchronized recowery mechanism. 
The Restart Program retrieves att the data base restart ijiata of Appti- 
cation Programs that witt be involved in the recovery mechanism» sorts 
it» and passes it to the MCS.j The Restart Program then goes to EDJ. 
The MCS atso executes the Restart Program if the previous run of the 
MCS terminated abnormally. 


GEMCOS supplies a documented COBOL source file of a sample Restart 
Program on the 4.00 release tape which is to be used wita DMS If. This 
sample demonstrates the proper passes of control from the Restart Program 
to the MCS» as well as the togic flow within the program. This sample 
source can be patched by the user to replace the naming conventions of 
the restart data set used by GEMCOS with the user'ts data names. This 
sampie source aiso contains documentation on the vaiues of th2 Coamon- 
area header field MCS-TYPE.j The onty required change to this source ts 
the data base name» and possibly the remote file name. Otherwises this 
source can be compiled and integrated tnto the system. 


RECOVERY CYCLE. 
The GEMCOS recovery cycle can be initiated tn any of the following 
ways: 


ae By the Network Controt Command REC. 


be When a user program passes the abort indicator pack to the 
MCS Ca message with MCS-TYPE set to 20). 


ce When the MCS is restarted after it has abnormally terminated 
or after the operating system has abnormally terminated. 


de. When an Application Program using recovery abnormally termi- 
nates (with the CLE Network Command). 


In the first three cases» recovery 15 initiated automati:saily when the 


Situation is recognized by the MCS. In the fourth case» recovery is 
indicated after the aborted program is cleared by the op2rator. 
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Any transaction which is recycled to a User Program during recovery 
is flagged with MCS“RECOVERY-STATUS of the Common~area sat to one of the 
following values: 


ae VALUE 0 - The system is not in recovery mode. 


be VALUE 1 = The system is in recovery mode caused by an 
Application Program abort. 


ce VALUE 2 - The system is performing an archivail recova2ry. 


d.- VALUE 3 = The system is in recovery mode caused by a Clear/ 
Start or an abnormai termination of the MCS. 


In additions a transaction which causes a User Prograa to abnormally 
terminate 1s resubmitted with the Coamon-area header field MCS“RETRY- 
COUNT incremented by one. The MCS always re~submits an aborted trans- 
action. The User Program must decide how to process the transaction. 


Figure 9-3 shows the sequence of events at a Control station during 
recovery after a User Program has abnormally terminated. Messages 
prefixed by (Cu) are messages that were entered at the station by the 
usere Messages prefixed by (s) are messages that were sent by the MCS 
to the station. Any other station that attempted to input transactions 
during recovery Cand was ignored) is informed that recovary is finished. 
A station that is idle during recovery is not informed that recovery is 
donee 


Cu) TRNI <data> 

Cs) *#ERROR 435 126 2: UNEXPECTED CLOSE FROM PGM - <nnn> 
Cs) 2? 127 TO INITIATE RECOVERY» CLEAR PGM - <nnn> 

Cu) *CLE <nnan> 

Cs) SOKS 

Cs) ?? 108 = BEGIN RECOVERY OF DATABASE ~- <mnam> 


€s) ?? 109 = END RECOVERY OF DATABASE - <maa> 


Fagure 9-3. User Program Abnormal 
Termination Recovery 
Cycle 


ARCHIVAL RECOVERY. 

It might become necessary to reconstruct the sequence of events perforsed 
upon the data base as initiated by the data communications network over 

a period of many days. Conditions necessitating such action agight arise 

7f OMS IIT reconstruction faits or if a program bug contaminat2s the data 

base. The archival recovery mechanism ts the means by which this recon- 

struction of events is accoaplished. 


Archival recovery uses the MCS~-created audit files from the original 
processing of transactions. To initiate archival recovery» the MCS 
is executed with switch 1 set to 1 (SW1 = 1)- After initialization» 
the MCS displays the following messages on the display consol2: 


> GEMCOS ARCHIVAL RECOVERY 

s ENTER ARCHIVAL SPECIFICATIONS 

The following coatroiting information must be supplied through the 
display console. 


ae The name of the data base to be recovered. 


be. The list of all programs in the data base that are to be 
recovered ors if all programs are to be recovered» then the 
word “ALL”. 


This information must be supplied in free format according to the 
following syntax: 


<archival recovery request> =::= RECOVER DATABASE 
<data base specificati ons> 


<data base specifications> :3:= <data base name> 
<program List> 


<program list> 23= <program name> / 
<program name> » <program List> / 
ALL 


Before initiating the archival recovery mechanism» the operator nust 
Insure that the data base on disk reflects a known “*good"™ state. The 
MCS may require previously dumped audit fittes which atso need to be 
loaded by the operator. If they are not present» the MCS pronpts the 
operator to load the necessary files. The archival recovery mechanism 
recovers only one data base per archivat rune If more than one data 
Dase needs to be recovered» separate archival runs are necessary. 


During archival recovery» no messages generated by Apolisation Programs 
are released to the stations and no tnput is allowed from any station. 
When archival recovery is finished» the MCS goes to End-0f-Job. Atl 
messages from the MCS during archival reccvery are sent to the display 
console.j If one or more programs are disabiled at the time of archival 
recovery» they are automatically enabled before archival recovery begins. 


Figure 9-4 shows a typical sequence of events and console traffic for 

an MCS archival recovery run. Messages prefixed by a Cu) are generated 

by the operator» and messages prefixed by an (s) are generated by etther 
the MCS or the MCP. When the archival recovery process is finished» 

the data base is recovered and the MCS can then be re~executed in "normal" 
mode to restart onctline processing. 


Cud EX GEMCOS/MCSs SW1 = 1 

Cs) GEMCOS/HCS = 1234 BOJ. 

(s) % GEMCOS/MCS = 2? 110 =: GEMCOS ARCHIVAL RECOVERY 

Cs) % GEMCOS/MCS 3 2? 111 = ENTER ARCHIVAL SPECIFICATIONS 

Cu) 1234AX RECOVER DATABASE TESTDB ALL 

Cs) % GEMCOS/MCS = ?7? 115 = BEGIN ARCHIVAL RECOVERY 

Cs) % GEMCOS/MCS = 2? 108 = BEGIN RECOVERY OF DATABASE - <nnn>d> 
Cs) Z£ GEMCOS/MCS = ?? 109 = END RECOVERY OF DATABASc = <nnn> 
Cs) 2% GEMCOS/MCS = ?? 116 = END ARCHIVAL RECOVERY 


Cs) GEMCOS/MCS = 1234 EOJ. 


Figure 974. MCS - Archivat Recovery Cycle 


CONCLUSION. 

Many different types of MCS~-TYPE messages are passed to and from the 
MCS during the recovery cycie. The following brief table provides the 
user with a quick» easy reference. 


Table 9-1 
Recovery Controi Messages 


MCS-TYPE Written 


Value by Definition and Usage 


MCS Sent by MCS to Restart Program requesting 
restart data be retrieved 


Restart 
Progran 


Sent by Restart Prograa to MCS. Contains 
restart data information for all prograns in 
the data base 


Restart 
Program 


Sent by Restart Program to MCS whenever a 
fatal error is encountered 


User 
Program 


MCS 
User 
Program 


MCS 


Sent to 
program 


Sent to 
progran 


Sent to 
to type 


Sent to 
DPEN. 


MCS by Application Program whenever 
encounters a DMS [I program abort 


Application Program by MCS informing 
that recovery is about to be tnitiated 


MCS by Application Program in response 
21 message 


Application Program by MCS at FILE 


Contains pertinent restart data 


information. 


Sent to 
progranr 


Sent to 


to type- 


Apptication Program by MCS instructing 
to close the data base 


MCS by Application Program in response 
21 message 


Burroughs has accepted responsibility for playing the major role in 
effectively recovering from systen failures and tin naintaining data 
base and network integrity in the process. GEMCOS provides a wide 
range of recovery capabilities» freeing the user from retovery concerns 
to the maximum extent possible. The highsLevel flexibility offered by 
the system allows the user to analyze application requirements and then 
select the recovery options best suited to meet specific data 
processing needs. 


SECTION 10 


STATION TYPES 


GENERAL} 

B 1800/B 1700 GEMCOS provides interface to four different types of 
Stations: AP300» MT65900» Routeheaders» and standard. This attribute 
is specified in a STATION statement within the STATION section of the 
TCL. Depending on the type dectlareds other parameters may also be 
required. 

at the time of the failure may converse with programs that ar2 not 
required in the recovery processe- Once the recovery prosess 1s completes 
all stations and programs are free to converse. 

The AP300 is a free-standing matrix printer capabte of operating with 
the data communications interface of a host system. 8 1000 GEMCDS 
provides the interface for on-line oderations between the AP300 and 
application programs. 


The AP300 has various options which may be programmatically Loaded 
into the printer from a host programe The AP300 has the capacity 
to send vartous status conditions to the computer. 8 1000 GEMCODS 
intercepts the status condition messages and displays them at the 
network controller station. Optionally» as specified by the user» 
GEMCOS forwards the status message to the program to which the 
AP300 is attached.j (This capability only exists if the AP300 is 
attached to an assignment progran.) 


MT600. 

The modular terminals» Csometimes cathed the soft terminal)» is a 
sophisticated forms processing system. When a form is created on the 
terminals» a program is also created to direct the processing of the 
form. After processings the form is stored either ina fite at the 
terminal or in the host processor. If the form is stored tn the host 
processors it is loaded down-line at a later timej By user specifications 
the program directs either some or alt data fields of the form to the 
host processor. Similarty» the form receives etther some or ail data 
fields. In addition to the memory aliocated for the form and the pro- 
grams» an additional memory area is available for direct communication 
with the host processor. This area is referred to as the command 
message areae 


To sort out this complex array of conamunications possibilities» special 
headers have been designed to precede messages and indicate the nature 
of the text being sent. With the exception of command massage area 
(C/M Area) messages» all messages from the modular terminai have these 
headers»e and all messages to the terminal are preceded by them. 
Furthermores ali messages other than continued C/M area and foras 
messages must be followed by a special traiter. 


The GEMCOS interface to the modular terminal does not inztude format- 
ting the input or output of the terminal. The interface capability 
serves to do the following: 


ae Determine the type of message that was input from the terminal. 
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be. Extract the trailer and header from the input m2ssage2. 
ce Determine the type of message to be output to the terminal. 


de Add the trailer and header Cextracted from the input message) 
to the output message. 


A onewcharacter field in the common area header serves to identify att 
message types» directed to or originating from application programs. 


PROCESSING INPUT FROM THE ATS. 

The GEMCOS system examines all messages from the MTS and determines 
whether a header its present tn eache. When no header is present» a zero 
is placed tn the message type field of the common area header. Zers 
indicates the message is from the common areae When the header is 
presents» the message type is taken from the header and placed in the 
message type field. The header and traiier are then removed frorm the 
message texte. Auditings routing and other types of processing proceed 
normaily. 


PROCESSING OUTPUT TO THE MTS. 

The GEMCOS system constructs the header for the response to the MTS by 
employing the message type that was received from the MTS in the 

common area header. Before the GEMCOS system constructs headers for 
return messages» it validates the message type. GEMCOS discards any 
messages having an invatid header identifications and sends an error 
message to the control station. When the message type is zero (0) in 
the message from the MIS» no header or trailer is sent with the message 
returned to the MTS. Otherwise» the header and trailer are created and 
sent with the MTS. 


MODULAR TERMINAL SYSTEM MESSAGE TYPES. 

The following List provides the valid message types that are tn the 
common area header of messages» passed between programs and the GEMNCOS 
system. 


0 = Send or receive to command message area 
2 = Send or receive total form definition 

-2 = Send or receive first buffer of total form definition 
3 = Send or receive condensed foram 


~3 = Send or receive first buffer of condensed fora, 
4 = Send or receive all data fields 

6 = Send or receive selected data fields 

7 = Recovery point message 

8 = Last continuation buffer (forms onty). 


-8 = Intermediate continuation buffer (Cforms only). 
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SECTION 11 


CONVERSATIONAL FEATURE 


GENERAL} 

The conversational feature is a unique method of communication between 
a participating program and aterninal.j Conversations involve three 
system elements: the station» the programs and the MCS. Participating 
program messages typically consist of the GEMCOS header and message 
texte In conversational messages conversation text is 2a mbedded 
between the header and the messagee Conversation text #8 only updated 
by the programe. When a program sends a messages the MCS removes the 
conversation text from the message and stores it in the zonversation 
area of memory. As new text is returned from the stations the MCS 
returns the conversation text to the message before delivering it to 
the program. 


Through this procedures the program is relteved from declaring tables 
or allocating memory for the conversation texts instead» thes2 tasks 
are assumed by the MCS. The MCS allocates a conversation table. Each 
conversation area is an element of the table. The MCS allocates the 
conversation table according to the maximum number adiiowed in the 
system simultaneously. Areas are only used and brought into memory as 
required. 


Stations may only converse with one program at atime. Converset y» 
programs may communicate with several stations simultaneously. Normally» 
program messages can stiil be sent to a station that is :onversing 

with a program. Each conversation is assigned one conversation area. 
There may be many conversational programs and conversational stations 

in the TCL.~ The MCS needs to maintain only one copy of the conversation 
table. This process eliminates duplicate information and reduces 

memory uSagee 


TCL SPECIFICATIONS. 

To create the conversational capability» three statements are used: 
CONVERSATIONLIMIT statement» CONVERSATIONSIZE statement» and 
CONVERSATIONAL statement. 


CONVERSATIONLIMIT STATEMENT. 

This statement determines the saximus number of stations that may 
converse concurrently. The statement is entered in the aLOBAL 

section. <Any conversation initiated which exceeds the limit eastablished 
with this statement causes an errore The initiat messag2 of the 
conversation which caused the error ts not sent to the tatended 
destinations instead» it is returned to the program with an error 

Status in the message header.j The program may either peritodicalty 
attempt to send the initial conversation message until a conversation 
area 18 available Ci.e.» until another conversation has been terainated) 
or» tt may send a message notifying the station operator of the 
temporary shutout. 


CONVERSATIONSIZE STATEMENT. 

The conversation size varies among programse The size its established 
for eachs using this statement. When several programs have conversa=~ 
tional capabilities» the largest conversation size among them is 
applied as the conversation size for all conversation areas. 


The conversation area attocated by the MCS may be much Larger than the 
conversation sizes specified for certain programse However» the MCS 
only provides the number of bytes required by each vrogram. Areas must 
be aitocated at the start of running a programs they cannot be allocated 
as required. Afterwards» the areas nay be used and assigned ad required. 


NOTE 
The message size dectared must be 
large enough for conversation mes- 
Sagese Conversation messages con- 
sist of a header» conversation texte 
and message texte. The MAXTEXTSIZE 
statement 31s used to establish the 
_message size. 


CONVERSATIONAL STATEMENT. 

This statement is used to assign the conversationat capasdility to 
Stations. It is assigned to a station being defined by assigning the 
value TRUE to the statements assigning the value FALSE exctudes a 
Station from the conversational capability. If a program attempts to 
communicate with a nonconversattonal stations an error otcurs. (For 
further information about this statements» refer to the STATION section 
of this publication.) 


All three statementse just described in this sections area declared in 
the TCL as follows: 


ae For the GLOBAL section Copticnal ): 


CONVERSATIONLIMIT = <nn>. 
(nn represents a twordigit number) 


be. For the PROGRAM section: 


1) CONVERSATIONSIZE = <nnn. 
Cnnn represents a three~digtt nuaber) 


2) INTERFACE = PARTICIPATION. 

3) AUDITOUTPUT = TRUE. 
(this attribute aust be declared for recovery of 
conversations) 


Ce For the STATION section Coptional): 


CONVERSATIONAL = TRUE. 
CTRUE 1s the default vaiue) 
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PROCEDURES _* OR CONVERSATIONAL PROGRAMS. 

It is the task of all conversatioral programs to indicate the beginning 
and the end of a conversation. They also include the conversation text 
in the message. Two fields have been added to the message header which 
enable the program to perform these tasks: the CONVERSATIONBOJEDS 
field and the CONVERSATIONSTATUS field. 


Once a program receives a messages the value of the CONVERSATIONSTATUS 
field indicates whether the path is clear for the messagee a conversa= 
tion is in progress at the stations or the message has caused an error. 
A definition for each value follows: 


0 - Path is clears either no conversation ts in progress» 
or the station 1S nonconversationai. 


1 - Conversation is in progress at the station. The value 
of the CONVERSATIONBOJEDOJS fieid indicates whether another 
program 1s conversing with the statton. 


2 ~ Error. The maxtmum nuaber permitted for simultaneous 
conversations has been exceeded. The Last program m2ssage 
is returned Cwithout the audit) to the program. 


3 - Errore Program attempts to tnitiate a conversation with a 
nonconversational station. The message is returned to the 
programe 


4 - Error. Program attempts to converse with a station which 
is currently conversing with another program. [The m2ssage 
is returned to the program» in error. 


5 - Error. A nonconversational program initiates a conversation. 
The message is returned to the program. 


The program designates the appropriate value for the CONVERSATIONBOJEDJ 
field in the message header. This field has one of two vaiues itn mes~ 
sages directed to a station. Definitions for both values follow: 


0 - No conversation in progresse MCS expects message text 
immediately after the message header. 


1 - Conversation 18s in progresse Conversation text follows the 
header and precedes the output text. It ts stored in the 
conversation areae However» if the program is being audited» 
both the conversation text and output text are audited. 
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In messages directed to a progran (ieees» from a station)» the 
CONVERSATIONBOJEOJ field has two possibile values. Definitions for both 


foltows 


0 - Unoccupied. This indicates 
conversation. 


i - Occupied. The program that 
Station receives this value 
from the station. 


A recomegended remote file record and 
presented in figure Lil. 
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the station is available for 


is currently conversing with the 
in each conversation message 


working storage definition is 


RECOMMENDED REMOTE FILE RECORD 
AND_ WORKING STORAGE DEFINITION 


OL REMOTEF ILE~RECORD. 
05 COMMON-HEADER. 


10 PIC 9. 
10 MCS-LSN-NBR PIC 9€3). 
19 MCS-OUTPUT-ADDR PIC 9€9). 
10 MCS“CONVERSATION“STATUS PIC 9. 
10 MCS“CONVERSATION-BOJEOJ PIC 9. 
05 MCS“USER “AREA PIC XCNI).] (#8) 
05 TEXT“AREA PIC XCN2). (#9) 
05 TEXT“WITH“CONV REDEFINES TEXT-AREA. 
10 CONVERSATION<-TEXT PIC X€N3).2 (#10) 
10 REGULAR=TEXT PIC XCN&)- (C#1L) 
WORK ING“STORAGE SECTION. 
01 WS-INPUT PIC X€N4). (C#il) 
01 WS*DUTPUT PIC XCN5). (#12) 
OL WS-CONVERSATION“AREA PIC XCN3). (#10) 


= 
2 


Figure Liki. Raconnended Remote File Record 
and Working Storage Definition 


ee 8 en Ge ee ee ee eee ees eee ee ee oe oe eee eee 


8 Ni represents the tength of the user portion of the common area header. 
If there is no user portions the MCS“USER-AREA should not be given. 


9 N2 represents the tength of the user text. 
10 N3 represents the length of the user's conversation texte 


11 N4& represents N2 minus N3- 


The proper sequence of events for a user program with conversational 
capabilities is outlined in the following basictlogic-flow example. 
(See figure L1i-i for remote file record and working storage 
definitions.) 


Examples 


PROCESS. 

READ MCSQUEUE AT END MOVE 1 TO EOF 
GO TO PROCESS~EXIT. 

IF MCS“TYPE = 24. 
<SEND "TYPE 25" MESSAGE> 
GOD TO PROCESS~EXIT. 

IF MCS“TYPE = 21 
<PRGCESS & SEND "TYPE 22" MESSAGE> 
GO TO PROCESS~EXIT. 

IF MCS“CONVERSATION“STATUS > 1 
<PROCESS CONVERSATION ERROR> 
GO TO PROCESS~EXIT. 

IF MCS“CONVERSATION“STATUS = 0 OR 
CMCS-CONVERSATION“STATUS = 1 and 
MCS~CONVERSATION“EQJEOJ = 0) 

* NO CONVERSATION TEXT IN MESSAGE 
MOVE TEXT“AREA TO WS~INPUT 
ELSE 
CONVERSATION TEXT IN MESSAGE 
MOVE CONVERSATION-TEXT TO WS“CONVERSATION-AREA 
MOVE REGULAR@TEXT TO WS~INPUT. 
<START PROCESS> 


IF MCS“CONVERSATION-BOJEDJ 0 and 
MCS“CONVERSATION“STATUS 
<NO CONVERSATION ALLOWED> 

MOVE WS-OUTPUT TG TEXT“AREA 
<OR BUILD OUTPUT IN TEXT-AREA> 

ELSE 
<MAY INITIATE OR CONTINUE CONVERSATION> 
<TO BEGIN OR CONTINUE CONVERSATION: > 

MOVE WS“CONVERSATION“AREA TO CONVERSATION“TEXT 
MOVE WS-OUTPUT TO REGULAR“TEXT 
<GR BUILD OUTPUT DIRECTLY IN TEXT“AREA> 

MOVE 1 TO MCS“CONVERSATION“BOJEOJ 


tou 
pt 


<NO CONVERSATION OR TO END A CONVERSATIDN> 
MOVE WS-OUTPUT TO TEXT“AREA 
MOVE 0 TO MCS~CONVERSATION-80JEO0J. 
<SEND OQUTPUT> 


PROCESS“EXIT. 
EXIT. 
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To avoid reducing recovery efficiency» programs aust terminat2 coa- 
pleted conversations» particularly at stations that continually 
receive nonconversational messages. 


RECOVERY OF CONVERSATIONAL PROGRAMS. 

The AUDITOUTPUT statement of a conversational program must be 
declared with the value TRUE tn the program section in order to 
recover conversation text after a system fatlure. Conversation text 
is recovered through audited output messages. 


Any conversations which are in progress when a system fatture occurs 
are recovered. New conversations are temporarily excluded from parti- 
cipating stations until the recovery process 1s complete. However> 
nonconversatitonal messages are permitted at all stations and programs 
while the system is being recovered. Stations that are not conversing 
at the time of the failure may converse with programs that ar2 not 
required in the recovery process. Once the recovery prozess 1S conm- 
pietes» ali stations and programs are free to converse. 


SUMMARY. 

The conversational feature provides various benefits. The number of 
file accesses are reduced by storing data that ts repeatedly used by 
programse Conversation areas are brought tnto memory as required. 
The number of copies of a program does not affect the area size 
allocated. Also» stations conversing with programs are only assigned 
one conversation areae These impssed Limitations eliminate duplication 
of information and reduce the space required to store station infor- 
mation for a program. Finally» access to certain transactions and 
programs can be controlted by restricting the number of stations that 
are assigned the conversational capanility. 
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APPENDIX A 


SUMMARY OF YFCL SYNTAX 


GENERAL - 

This appendix describes the TCL syntax using “railroad track" dtagraas. 
It is provided as an alternative to the Bachus-Naur form used to 
describe the TCL syntax in section 3. The following rules apply to the 
syntax diagrams: 


ae Any path traced ationg the forward direction of the arrows 
produces syntactically vatid TCL source code. 


be Any “bridge” over a digit may be traversed a maximum 
number of times specified by the digit. If the digit is 
followed by an asterisk (*)» the path must be crossed 
at Least once. 


ce Uppercase Letters in the syntax diagrams indicate key 
words which are lLiteraliy itn the statement. 


d.- The (darkened square) indicates the end of a TCL 
source file. 


e. Lowercase Letters» words and phrases enclosed aithin 
angle brackets (< and >) are either references to an 
intermediate diagram or syntactic vartables»s which 
represent information to be supptied by the user. 


f.- The Cundarkened square) indicates the end of an 
intermediate diagram. 


ge A <fite-ID> is a B 1800/8 1700 file identifier. Refer 
to B 1800/8 1700 Systems Software Operational Gutde» 
form 1068731. 


he A <remote file-ID> is a LO-character identifier defined 
in the FILE section of NDL. 


ie A CStation name identifier> is a 10-character tidentifier 
defined in the STATION section of NOL. 


je ALL other TCL identifiers may contain alphanumeric 
characters. Identifiers have no intrinsic meaning. 
They are used to name access codes» programse trancodes» 
messages» formats and functions. The <access code 
tdentifiers> and <message identifiers> may not exceed 
6 characters. <Trancode identifiers> may not exceed 
10 characters. <Program name identifiers>» <for mat 
identifiers> and <function identifiers> should not 
exceed 390 characters. 


ke. A <string> is any number of characters enclosed within 
quotese A <string> must begin and end on the same 
TCL source record. 


APPENDIX A Ccont) 


Ll. 


Ne 


Oe 


De 


An <external string> or an <internal string> is a 
<string> of 6 characters or less. 


An <EBCDIC unit string> is a <string> with exactly 
one character. 


A character is A thru Z» 0 thru 9s or any valid special 
character. A character is not enclosed within quotes. 


An integer is a string of digits (0 thru 9). 


For a definition of a <UPL DECLARATION statement >» 
<UPL DEFINE statement>» <UPL FILE statement>» <UPL 
DYNAMIC DECLARATION statement> or <UPL PROCEDURE 
statement>» refer to the UPL Reference Manual>» 
form 1067170. 


Figures Aw1 thru Aw20 depict the TCL syntax using “railroad track” 


diagrams. 


Aw2 


£-¥ 


————_ 


CONTROL = 


COMPILE 


= < GLOBAL section > ——& < DEFINITION section > sul 


Sci 
taare@ Aw1ie Syntax o f <MCS IC 
ne deck descripti on> 


(2uU03) VY XIGNIJddV 
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GLOBAL: 1 CHANGEREQUESTS = TRUE . .; 


DATADUMP Ene FALSE Zz 


1 
}“— MESSAGEBROAOCAST ———— 
1 ~~ MESSAGERECALL 
1 
1 


PROGRAMBOJSEQJ ————__» 
MONITORTRACE ——___—__» 
7\— STATUSREPORTS ————__—__» 
7U—SYSTEMHALT 
]\—— SIMULATION 
1—~ MONITORTRACEON 
-S4\— COMPILEOPTIONS ————————- =~ <string >- 
1 “— OBJECTCODEFILENAME -= ——4»< file-ID > 
CRIN, 
AUDITFILEPACKID = ——®< identifier >— 
RECALLPROGRAM 
NAMESTACKENTRIES 
VALUESTACKBITS 
AUDITPAGESIZE 
MAXTEXTSIZE 
MAXRUNNING 
QUEUEDEPTH 
QUEUEBUFFERS 
AUDITRECORDSIZE 


1 CHECKPOINTINTERVAL 
1 CONVERSATIONLIMIT 


1 NCCOKRESPONSE 4 « ——t=< character > 
1 SIGNALCHARACTER 
| —-QUEUENAME ————————————— > = —<remote file-iD > 


CONTROLSTATIONS ———_——_——_————- = ——s>< station name > 
identifier 
< FORMAT AND FUNCTION statement > 


ond 


= -———— BE < integer > 


ee ee See See ee ee ee See ee 


wed 


Figure Aw2- Syntax of <GLOBAL section> 


——f BEGIN ———P <ACCESS CONTROL statement> ————® <PROGRAM section> —_—___—-§( 


($——t <STATION section> © ———® < DEVICE section > ———® < MESS CODE section>—— END a ae 


Figure Av3. Syntax of <DEFINITION sectiton> 


ACCESSCONTROL: ACCESSKEY -———® <access code identifier > —— = ALL 6 
? 


identifier 


<trancode > | 


< program name > 
identifier 


Figure A-4&. Syntax of <ACCESS 
CONTROL statement> 


G-V 


€2U03) VY XIQN3dd¥ 


GeV 


1 TITLE —e © —e <{ile-ID > 


e EGG pee eanere eet retenenmistas 
TRANCODE—e = a 


identifier? | 
( <integer > <Integer >) 


1 RESIDENCE —» = “ DISK 7 
CORE 


PROGRAM —& <program name > 
identifier 


1 EXECUTE— = ON DEMAND 
BOJ 
MANUAL 
1 COMMONSIZE ————————_——» = — <integer > 
1 \—m MAXCOPIES 
__(T\- = MAXASSIGNERS 
| 7 \V me CONVERSATIONSIZE 
—S}\—» OPENMESSAGE - TRUE 
1 ATTACHMESSAGE ip anes 
—f\— DETTACHMESSAGE 
1 AUDITASSIGNMENT 
1 \_» AUDITOUTPUT 
—S\_-» RESTARTPROGRAM 
1 INTERFACE ——_—_——__—_» = MCS 
PARTICIPATION 
NONPARTICIPATION 
—f4\— RECOVERY ——_—_—______» « SYNCHRONIZED 
DATABASE 
QUEUERESTORATION 
NONE 
—}\— DATABASENAME—————_> = <identifler > 


g 
™ < trancocde Identifier > _L 


ALL 


| AUDITTRANSACTIONS ——™ 


Figure A-5. Syntax of <PROGRA™M section> 


€2U09) WV XION3ddV 


s-¥ 


—_—_——Lgy STATION ——pm <station name> 
identifier 


—> : 


1 SIGNON -——" = he TRUE : 
pause —! 


1. SCREENSIZE __ = ———pe <integer> 
1 TRANCODEPOSITION 
i VALIDACCESSKEYS —® = ALL 


 ] 


<access code> 
identifier 


Figure Aw6s. Syntax of <STATION section> 


’ 
 ] 
DEVICE -®<device name> : —® STALIST= pa I ‘ 1 FORMATSIN: <format> —m = | ag 3 ° 


identifier identifier identifier 


? 
<format > —® = | ene « 


identifier identifier 


1 FORMATSOUT: 


Figur2 Aw7. Syntax of <DEVICE sectton> 


(3u03) ¥ XIOGN3dd¥ 


f=¥ 


i STATIC DECLARATIONS: 


<UPL DECLARATION statement> 


<UPL DEFINE statement> 
K UPL FILE statement> 


ENDSOURCECODE, 


DYNAMIC DECLARATIONS S=<UPL DYNAMIC DECI ARATIONS es i ENDSOURCECODE, 


PROCEDURE l AUDIT 
| CLOSEACTION 


: -&< UPL PROCEDURE statement >-™ENDSOURCECODE, 


| + CLOSEFILES 
| 4» ERRORHANDLER 
| “> MSGF ROMPROGRAM 
1 Le MAINTENANCE——> 
| “> MSGFROMSTATION 
yb» UPENACTION 

) “> HANDLERECALL 

| > INITIATERESTORE 

| + RESTOREPROGRAM 
| -SETSIZES 

| “> SETVALUES 


Figure A738. Syntax of <MESS CODL section> 
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6-¥ 


—® FUNCTION 


function 
identifier 


< function declaration > 


> 


Figure A~-3. 


< format declaration > 


Syntax of <FUNCTION and 
FORMAT statement> 


L Siesintessp elie ge clianerp manne aae 8 


mee 


INTEGER 
ALPHA 
UNEDITED 


Figure 


,INTERNAL3+-® INTEGER ] 


UNEDITED 


A-10. Syntax of <funzstion 
dectaration> 


-— 


—Externap i < 


string 


internal 
string 


>) 


cquo3) y XIGNIddV 


OT-¥ 


—& FORMAT 


VARIABLE 


jae | 
< alll > (—> <local declaration part> — ge <editing spec.> 


identifier 
a, 


Figure Aw1ile Syntax of <for mat 
declaration> 


i V1- FOR -——®<integer> 
| V2 


| V3 


@Q ————_—__» <integer> 


i V4 
| V5 
| V6 


Figure A-12. Syntax of <local 
declaration part> 


CJU0I) WV XEQNIdd¥ 


9 


<editing string> 


<item phase > 
@ Ea <integer > 
+ 


Figure Aw13. Syntax of <editing 
specification 


X ——& <integer> 
X —pP ( <EBCDIC unit string> ) 
Sans unit string> _ 
<string> 


4 ———& < hexadecimal string> 


Figure Awr14.—e Syntax of <editing string> 


Tt-¥ 


(3U09) VW XION3dd¥ 


A 7 <field width> 


<integer > 
i 
; B 
vanieuie > —p» OR —» <integer> J 
. identifier 
variable ain 
identifier : ( —™& <editingspec.> -——p) 
T(—»< qunerien 9 <field width> —gm 9 — <internal size> -»>) 
identifier 


Figure Aw15~- Syntax of <item phrasa> 


L <integer > 
( | unit string> Zu 9 —p} <integer> -») 
<hex unit string> 


Figure Aw16. Syntax of <field width> 


C3U0D) WV XIGN3dd¥ 


£t-¥ 


V1 
V2 
V3 
V4 
V5 
V6 


Figure Awt17~- Syntax of <yariable identifier> 


—_——_ > <integer> —>| | 


Figure A-13. 


— 4/ 


Figure A-19. 


Syntax of <internal size> 


uf] 


“™mUOQ WP © e een — © 
"“™mMOOwPYPOeeend —= © 


Syntax of <hex unit string> 
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CH NoeoontCModwue 


Oe—-Nesentmaoguu 


Figure A=-20. Synatax of “<hexadecinal string> 


APPENDIX 8B 


SUMMARY OF NETWORK CONTROL COMMANDS 


GENERAL. 

This appendix summarizes the network control commands. Refer to 
NETWORK CONTROL COMMANDS in section 3 for a definition of syntax 
conventionse 

DECURITY CONTROL COMMANDS. 

SIGN ON. 


* SGN user~ID 


SIGN OFF. 
* BYE 
ENABLE USER. 


* EUS userwID 


DISABLE USER. 


* DUS user-ID 


PROGRAM CONTROL COMMANDS. 
EXECUTE PROGRAM. 

* EX program-name execute~option-List 
HALT APPLICATION PROGRAM. 


* HAP program-name 


MCS_CONTROL _COMMANDS- 
AUDIT OK. 


* AQK 


HALT SYSTEM. 


* HLT KILL 
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MESSAGE CONTROL COMMANDS .} 
BROADCAST. 


* BRC Cstation~specifier] ee. * message~text 


POP QUEUE. 
* PQ Station~specifier~1 ALL PRINT 
SEND station-specifier-2 


REPORT COMMANDS} 
REPORT DATA DUMP. 


* ROM PRINT 


REPORT FILE STATUS. 


* RFS Cfile-name ] 


REPORT PROGRAM STATUS. 


* RPS (Cprogram~-speci fier] 


REPORT PROGRAM COUNTERS. 


* RPC Cprogram-spect fier ] 


REPORT STATION STATUS. 


* RSS Cstation-speci fier ] 


REPORT STATION COUNTERS. 


* RSC (station-speci fier } 
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CHANGE COMMANDS - 
CHANGE MONITOR FLAG. 


* CMF Cflag-number] eee ° 


CHANGE STATION ADDRESS. 


* CSA station-speci fier address 


CHANGE STATION DIAGNOSTIC. 


iz 


* €3)0 station-speci fier 


CHANGE STATION FREQUENCY. 


* CSE station~speci fier frequency 


CHANGE STATION MAX“RETRY 


* CSM station-specifier retries 


CHANGE STATION QUEUE. 


* (39 statiton~specifier1 station-specifier-2 


CHANGE STATION READY. 


* CSR station~speci fier 


iz 


CHANGE STATION TRANSMISSION NUMBER. 


* CST station-speci fier trans mission“nusaber 
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APPENDIX B (cont) 


AUDIT_AND_ RECOVERY COMMANDS» 
REFRESH. 


* REF 


CLEAR DISABLED PROGRAM. 


* CLE program~speci fier 


RECOVER DATA BASE. 
* REC {data base specifier) 
RESET BUSY STATUS | 


* RBS station specifier 
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APPENDIX C 


SYSTEM REQUIREMENTS 


GENERAL» 
Peripheral hardware needed to generate and execute a GEMCOS MCS 
includes: 


ae Card reader. 
be. Line printer. 
ce Console printer/keybdboard. 


de Disk subsystem. (CIf AUDIT is used» at Least 4.6 
megabytes are recommended» inctuding MCP and Net work 
Controller requirements but excluding user data 
files.) 


ee SingterlLine or multiline control. 


A minimum of 24K bytes of main memory Cexclusive of MCP requirements) 
Is needed to generate an MCS. The smallest MCS that can be generated 
requires 7K bytes Cexclusive of MCP and Network Coatroitler require- 
ments). Memory requirements increase for each option generated and for 
each additional entry in MCS tables. 


The fotlowtng chart can be used to estimate memory requirements in 
bytes for an MCS generated by the GEMCOS system. The calculation of 
the run structure as performed by the generator is a relatively complex 
process» and this chart is a simplification of it. Thus» the nuaber 
calculated here is only an estimate of the memory requirements. It 
should be accurate to within 10 percent of the actuai value. 


The memory requirements for resident formats are difficult to esti- 
mate and it is assumed in the aigorithm used in the chart that alt for- 
mats are to reside on diske To determine the amount of memory required 
for resident formats» compile the format descriptions with MCSTCL 
setting LIST in the <CONTROL statement>.j The printer file ltabeled 
MCSRPT well be produced. Consult the pages which refer to FUN and FOR 
records adding the “Lengths™ of atl functions and formats where 
“residence” is i. 


Note that the memory requirements of a B 1700 object code file can be 
obtained with the CODE/ANALYZER program found on a systems release tape. 
However» in the case of a GEMCOS MCS» the calculation of the file space 
is not entirely correct since the MCS modifies several attributes of 
its files at run time. 
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FILE SPACE. 

MCS QUEUE 
Enter MAXTEXTSIZE on Line 1. 
Enter 50 on Line 2. 
If any program uses the PARTICIPATION 
interface enter 200 on line 33 otherwise 
enter 0. 


Add lines 1» 2 and 3 giving line 4. 


Enter the number of stations defined in 
the <STATION section> on Line 5. 


Enter 5 on Line 6. 
Multiply lines 5 and 6 giving Line 7. 
Enter QUEUEBUFFERS~-1 on Line 8. 
Enter Line 4 on line 9. 
Multiply Lines 8 and 9 giving tine 10. 
MCSTIC 
MCSPRINT 


If MONITORTRACE is TRUEs enter 248 on 
line i3.e 


MCSAUDIT 
Enter AUDITRECORDSIZE on Line 14. 
Enter 357 on tine 15. 
If AUDIT is TRUE» add Lines 14 and 15 
giving Line 16% otherwise» enter 0 on 
line 16. 

MCSOLDAUDIT 


If RECOVERY is required» enter tine 15 
on line 175 otherwise enter 0. 


Add lines ll» 12» 13» 16 and 17 giving 
line 18. 


14) 


15) 


15) 


18) 


231 


S 


Pan + 


RUN STRUCTURE NUCLEUS 

Enter 337 on line 19. 19) 
F.1.B8- dictionary 

Enter 80 on Line 20. 20) 
GLOBAL VARIABLES 

Enter 368 on line 21. 21) 

If DATA DUMP is TRUE» enter 3 on Line 22. 22) 


If MESSAGERECALL or CHANGEREQUESTS ts 
TRUE» enter 37 on Line 23. 23) 


If PROGRAMBOJEDJ is TRUE» enter 6 on Line 24. 24) 
If any program uses an interface of 


PARTICIPATION» enter 203 on Line 25. 25) 
If SYSTEMHALT is TRUE» enter 5 on Line 26. 26) 
If AUDIT is TRUE» enter 36 on Line 27. 27) 


If recovery ts synchronized for any program» 
enter 234 on tine 28% tf RECOVERY = DATABASE 
or QUEVERESTORATION for any programs enter il 


on line 28. 28) 
If the MCS ts to format any message» 

enter 13 on line 29. 29) 
If the MCS is to provide access control» 

enter 35 on Line 30. 30) 
If a CONTROLSTATION is specified» 

enter 5 on tine 3i. 31) 
If any network control command is to be 

supporteds enter 178 on Line 32. 32) 
Add Lines 21 through 32 giving line 33. 33) 


GLOBAL TABLES AND MESSAGE AREAS CExctluding formatting) 


If any program uses an interface of 
PARTICIPATIONs enter 203 on Line 34. 34) 


If any kind of recovery is required» enter 
AUDITRECORDSIZE + 30 on tine 35% af only audit- 

ing is required» enter AUDITRECORDSIZE on Line 

35-6 35) 
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Enter MAXTEXTSIZE on tine 36. 
Enter 55 on Line 37. 


Enter the number of stations defined 
in the station section on line 38. 


Enter 91 on Line 39. 
Multiply lines 38 and 39 giving Line 40. 


Enter the sum of all copies of all orograms 
on line 41. 


Enter 51 on Line 42. 
Multiply Lines 41 and 42 giving line 43. 


Enter the number of trancodes defined in the 
PROGRAM section on tine 44. 


Enter 13 on Line 45. 
Multiply lines 44 and 45 giving line 456. 


Enter the number of programs defined in 
the PROGRAM section on line 47. 


Enter 9 on Line 48. 
Muitipty lines 47 and 48 giving line 49. 
Enter Line 38 on Line 50. 

Enter Line 43 on Line 51. 

Enter Line 46 on line 52. 

Enter 49 on Line 53. 

Add tines 50 through 53 giving line 54. 
Multipiy lines 50 and 54 giving line 55. 


Enter 8 on line 56. 


If an <ACCESS CONTROL statement> is present» 
divide line 55 by Line 56 giving line 57. 


Add lines 340 359 360» 37» &00 4&3» 462 
49 and 57 giving line 58. 


36) 


37) 


38) 
39) 


40) 


41) 
42) 


43) 


45) 


46) 


47) 
46) 
49) 


50) 


52) 


GLOBAL FORMATTING TABLES AND MESSAGE AREAS 


Enter Line & on line 59. 


Enter number of functtons d2afined on 
line 60. 


Enter 3 on tine 61. 
Multiply Lines 60 and 61 giving line 62. 


Enter the number of formats defined on 
line 63. 


Enter 3 on line 64. 
Multiply tines 63 and 64 giving tine 65. 
Enter tine 60 on Line 66. 


Fnter the number of message-IDs defined 
in the DEVICE section on Line 67. 


Add tines 66 and 67 giving Line 68. 


Enter the number of devices defined in 
the DEVICE section on iine 69. 


Multiply lines 68 and 69 giving Line 70. 
Enter 10 on Line 7i.- 
Multiply lines 70 and 71 giving Line 72. 


Enter 8 on Line 73. 


Divide line 72 by line 73 giving line 74. 


Enter tine 67 on Line 75. 

Enter 6 on line 76. 

Multiply lines 75 and 76 giving 77. 
Enter 384 on tine 78. 


Add iines 59s 62» 65» he 77 and 78 
Giving Line 79. 
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GLOBAL PROCEDURE VARIABLES 


If MONITORTRACE 3s TRUE» enter 45 on 


Line 80. 


Enter 145 on tine 81. 

Enter 0 on line 82. 

Enter 18 on tine 83. 

If stations have been assigned 

SCREENSIZE vatues in the STATION sections 
add lines 82 and 83 giving Line 84. 

If DATADUMP is TRUE» enter 303 on line 85. 
Enter 0 on iine 86. 


Enter 0 on line 87. 


If AUDIT tis TRUE» add Lines 86 and B87 
giving tine 88. 


Add lines 80» 81» B84» 85 and 88 giving 


Line 89. 


LOCAL VARIABLES 
Enter 41 on line 90. 


If any network control command is to be 
supported» enter 170 on line 91. 


If any message is to be formatted» 
enter 315 on line 92. 


Enter 123 on line 93. 


Enter largest value of lines 9i» 92 and 
133 on Line 94. 


Add lines 90 and 94 giving line 95. 


80) 


81) 


82) 


8 3) 


84) 
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MESS CODE 
Enter the number assigned to 
VALUESTACKBITS on Line 96. 96) ___ 
Enter 8 on tine 97. i ie eee 
Divide tine 96 by Line 97 giving line 98. ae 
Enter the number assigned to 
NAMESTACKENTRIES on Line 99. 99) 
Enter 3 on tine 100. 100) _._ 
Muitiply lines 99 and 100 giving Line 101. 101) ._. 
Add tines 98 and 101 giving ltne 102. 102) 
Add Lines 199 20% 332 58s 79» 89e 95 
and 102 giving line 193. 103) ss 
Compute 10Z of Line 103 and enter on 
line 104. 104) __ 
Add tines 103 and 104 giving line 105. 105) ___ 
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QTHER MEMORY CONSIDERATIONS. 


DICTIONARY CONTAINER 106) ___30 
MASTER CODE SEGMENT DICTIONARY 107) ____30 
MEMORY LINKS 109) ___ 400 

Add lines 106 through 109 giving tine 110. 110) _ 2150 


Add lines 18» 105» and 110 giving the 
Estimated Memory to Run: 


MCSTIC FILE DISK SPACE REQUIREMENTS. 
A record in the MCSTIC file is 180 bytes Longe The file normatly 
contains from 490 to 100 records. 


AUDIT FILE DISK SPACE REQUIREMENTS. 

The disk space used for audit files depends greatly on the operational 
procedures used at a specific installation. The system must be able to 
hold at Least two audit files on disk at one time since audit files can 
be stored on some off-line medium such as magnetic tape when ciosed. 


A record in an audit file is 180 bytes by default.j If AUDITRECORDSIZE 


is specified» the tength of the record is determined by the user. The 
fale contains AUDITPAGESIZE*40 records. 
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APPENDIX D 


MCS OUTPUT MESSAGES 


GENERAL» 

This appendtx describes all network messages which the MCS generates to 
inform users of errors or other conditions. The general format of a 
system or data communications error message is: 


*x*FRROR ama nn = error message 
The general format of an operator message is: 
72 nn = message 


The number nnis the message numbere The number mam identifies the 
procedure which discovers the error and 1s provided to atd in debugging. 


If DATADUMP = TRUE were specified in TCL» alt error messages nusbered 
dess than or equal to 30 are accompanied by a tabie dump. For other 
messages» a dump can be obtained by using the RDM Network Control 
Command. 


Q_INVALID_HALT. PHASE. 
During system shutdowns the current phase of shutdown is different from 
the one expected. 


SUGGESTED ACTION: 
Orderly shutdown may not be possibile» and the MCS may have to be 
discontinued. 


A_UINVALIOD_ STATUS REQUEST. 

During initialization» the MCS was sending status requests to the 
Network Controlier and the Network Controtler responded with an error 
message stating that some request was not valid. As a result» the 
corresponding entry in the MCS tables is not initialized. 


SUGGESTED ACTION: 
Discontinue the MCS» and execute it again. 


Z2_HARDWARE EXCEPTION ON MCSTIC. 

While reading from or writing to MCSTIC» the MCS detected a physical 
disk error (such as a parity error). The MCS suspends itself awaiting 
keyboard input from the system operator. 


SUGGESTED ACTION: 

If the operator responds to the ACCEPT» the MCS attempts to shut down 
either gracefully Cif SYSTEMHOLT = TRUE was specified in TCL) or 
directiy.j Otherwise the user must DS or DP the MCS. 
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3_EQE_ON SCSTIC_ READ OR WRITES 
The MCS attempted to read froa or write to MCSTIC using an invalid 


record number. The MCS suspends itself awaiting a response from the 
operator to an ACCEPT. If the operator respondss the MCS attempts to 
terminate normatly. 


SUGGESTED ACTIONS 

Analyze the dump for possible software error. Check the NPR record in 
MCSTIC for invalid record pointers. <A new MCSTIC may have to be 
created. 


&_INVALID_ RECORD _ TO_IN_ NCSTIC. 

The MCS read a MCSTIC records but the ID field at the beginning of the 
record was not the one expected. The MCS suspends itself awaiting a 
response from the operator to an ACCEPT.j If the operator responds» the 
MCS attempts to terminate normaliy. 


SUGGESTED ACTION: 

Anatyze the dump for possible software error. Check the NPR record in 
MCSTIC for invalid record pointers. <A new MCSTIC may have to be 
created. 


2 2NVALIO QUTPUT MESSAGE = VARIANT. 
The send routine detected an error in the header of a message that some 
other procedure was trying to sende 


The meanings of the different possible variants are described below: 


ae HARDWR. An attempt was snade to send a message to a station 
which cannot receive messages because of tts hardware type 
Csuch as a card reader )- 


be TYPE.j The message type field in the header does not have a 
valid value. 


ce SIZE. The message text size field in the header is greater 
than the maximum text size as declared at generation. 


de LSNe The Logical Station Number in the header is invalid. 


SUGGESTED ACTION: 

In all of the above casess» the message cannot be sent and is dropped. 
It can be recovered from the data dumpe This dump should be anaiyzed 
for a possible software problem. 


6 INVALID MESSAGE SOURCE ON SEND» 
When attempting to send a response to a Network Control Command» the 
MCS discovered that the LSN in the header was invalid. 


SUGGESTED ACTIONS 
The message cannot be sent out and is dropped. It can be recovered 
from the data dump. 
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B_CONVERSATION MISMATCH IN AUDIT FILES 


The MCS attempts to perform arecovery. The conversation inforsation 
in the MCSTIC file does not match the audit records. 


SUGGESTED ACTION: 
Review the audit fites and rerun the MCS programe. If the error 
recurss execute a data dump and aonitor trace. 


10_ INVALID MESSAGE VARIANT- 


The MCS has received a message from the Network Controller whose 
variant field ts not zero. 


SUGGESTED ACTIONS: 
The message 1s discarded» but can be recovered from the dump. The 
Network Controiler is suspect. 


AL1_INVALID -2LE OPEN = STATION MYUSE. 
An Application Program attempted to o3en a remote file containing a 
Station whose MYUSE ts not consistent with the open type. 


SUGGESTED ACTION: 
The Application Program must be discontinued. Either its OPEN aust be 
modified or the MYUSE of the station must be changed in NDL. 


12_INVALID FILE CLOSE - VARIANT. 

An Application Program tried to close a remote file which it did 

not previously open. The close request is ignored. If "variant" is 
INVALID PROG NUMBER» then the program does not have any remote files 
opens 1f FILE NOT OPEN» then itt has at teast one other remote file 
OpeNne 


SUGGESTED ACTION: 
Scrutinize the Apptication Prograsa for possible Logic fiaws. 


15_GO000_ RESULTS RETURNED BAD LSN_-_LSN. 
The MCS received a good results reply message from the Network Controt- 
ler» but was unable to recognize the station indicated by LSN. 


SUGGESTED ACTIONS: 
Check MCS and Network Controller interface logic. 


16_ UNEXPECTED GOOD RESULTS FROM LSN -_LSNe 
The MCS received a good results reply message from the Network Control- 
fer for a station that was not expecting one. 


SUGGESTED ACTION: 
Check MCS and Network Controtler tnterface logic. 
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17_RECOVERY OPENED CURRENT AUDIT FILE. 


During recovery» the MCS attempted to open the current audit file for 
message reprocessing. 


SUGGESTED ACTION: 
Rerun the MCS. If problem persists» obtain a data dump and monitor trace. 


18_BAD_ AUDIT RECORD DURING RECOVERY. 
During recovery» the MCS attempted to read or write an audit file 
with an invalid keys 


SUGGESTED ACTIONS 
Rerun the MCS. If problem persists» obtain a data dump and monitor trace. 


This error tmmediately follows the error explaining the natur2 of 
the problem. 


SUGGESTED ACTION: 
Check the Logic of the Restart Program as well as any Application 
Programs involved. 


20_BAD_FILE_# IN DETACH MSG. 
The MCS received a detach message from the Network Controtier but was 
unable to associate the remote file number with any known progras. 


SUGGESTED ACTION: 
Check the MCS and Network Controller interface Lojzyic and analyze the 
data dump Cif present) to obtain the orogras name. 


21_ BAD PGM # IN_DETACH MSG. 
The MCS received a detach message from the Network Controttier for a 
program that was not running. 


SUGGESTED ACTION: 
Check the MCS and Network Controller interface and corresponding data dup. 


31_ POSSIBLE _FRACTURED_ FORMAT _AT_LSN_<LOGICAL STATION NUMBER>. 

Screen wraparound sent a message containing a forsaat to the indicated 
Station. This is a warning message indicating that the format couid 
be split in the middle of a forms field. 


32_OQPEN DENIED - MAXCOPIES EXCEEDED. 
An attempt made to execute more than the maximum number of copies of 
a given program. 


SUGGESTED ACTION: 
DS or DP the suspended program. Regenerate ICL if program is a User 
Program and more copies are desired. 
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33_CANNOT_HAP_UTiIL_PGM FROM SPO OR CRD. 

An HAP Network Controt Command cannot be entered from the console 
printer or the card reader for programs which have been described tn 
TCL as a Utility Program. 


SUGGESTED ACTION: 
Enter the command at the station(s) which entered the EX command for 
this program. 


34 _ QOPEN DENTED = _ QPEN QUTPUT CONFLICT. 


A program opened a remote file output only but the MCS detectsed one 
or more of the fottowing conflicts: 


ae Program must be deciared NONPARTICIPATION. 
be. Program must not be an MCS. 
ce Program aust not be a User Program. 


SUGGESTED ACTION: 
Re~evaluate program requtrements and either modify program rerote file 
open or modify TCL. 


36 _QOPEN_ DENTEO = SYSTEM SHUT DOWN. 
An Application Program attempted to open a remote file during systeam 
shutdown. 


SUGGESTED ACTION: 
The program sust be discontinued. 


37_QPEN DENTED ON_REMOTE FILE. 
An Application Program attempted to ooden a remote fite to which no 
stations could be attached. 


SUGGESTED ACTIONS 
Check the FAMILY statement in the FILE section of NDL and the STATION 
section of the TCL deck. 


38_ SYSTEM GOING DOWN. 


This message is sent to any station which attempts to enter a message 
during system shutdown. The input message is ignored. 


22__INVALID PROGRAM NUMBER. 
The MCS has detected that a program has gone to EQJ but is not recog~ 
nized by the MCS as an active programe 


SUGGESTED ACTION: 

Use the RDM PRINT Network Controi Command and the DM console keyboard 
commands to obtain diagnostic information. A monitor Listing may also 
be hetpful. 
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40__PROGRAM_NOT KNOWN. 


A program not defined in TCL was referenced in an EX or AAP Network 
Control Command. 


SUGGESTED ACTION: 
Use the RDM PRINT coamand to obtain a tist of valid names. 


41_INVALID PROGRAM NAME PROGRAM“NAMES 
The program named in the Network Control Command either does not exist 
or does not have a remote file open. 


42__PROGRAM_NOT_IN_OISK DIRECTORY PROGRAM=NAME. 


The program name in the EX Network Control Command is not on disk. 


43__INVALID STATION NAME STATION=NAME® 


The station name in the Network Control Command was not recognized. 


44__NO ACTIVE FILE NAMED FILENAMES 
The file named in the Network Control Command either does not exist or 
has not been opened. 


&5__INVALZD_INPUL_MESSAGE_=-_ VARIANT. 
When reading from its input queues the MCS detected an error in the 
input messagee The type of error is identified by the variants: 


ae TYPE. The message type is not in the range 0 thru 4. 


be. SIZE. The text size is greater than that which the TCL 
parameter MAXTEXTSIZE altows. 


In either case the message 1s ignored» but ts printed for debugging 
purposes. 


SUGGESTED ACTION: 

A type error tn a message from an Apptication Program means that the 
program has put a value other than 0 (zero) in the type fieid of the 
actuat key. Incase of a SIZE errors tonger messages can be atlowed 
by changing MAXTEXTSIZE and regenerating. 


46_INVALID OPERATION MNEMONICS 


The Network Control Command mnemonic was not recognized. 


47_INVALID OPTION JTEM. 
Some item expected as an option in a Network Control Command is 
invalid. 


48_ INVALID CHANGE DATA ITEM. 
The value of a data item in 
invalid. 


a Change Network Control Command is 


49__COMMAND MISSING DATA ITEM. 
An ttem is missing from a Network Control Command. 


APPENDIX D Ccont) 


20__EX COMMAND IGNORED =_STA_ ATTACHED.) 


An EX Network Control Command was entered froma a station when the sta- 
tion was already attached to an Asstgnment or a Utility Program. 


SUGGESTED ACTION: 

If the station is attached to a Utility Programs enter an HAP for that 
program and retry the EX. If the station is attached to an Assignment 
Programs all EXs from this station waitl return an error until the 
Assignment Program closes its remote fite. 


21__EX COMMAND LOCKOUT =-_TRY AGAIN. 
The EX command was temporarily not availables therefore» retry the 
commande 


22_TRANCODE*S _PGM NOT ONDEMAND. 


The station entered a valid trancodes but the program is not currently 
executing and was not declared in TCL with the statement “EXECUTE = 
ONDEMAND*”. 


SUGGESTED ACTIONS 

Send a message to the CONTROLSTATION Cor system operator) requesting 
that the necessary program be executed or regenerated with EXECUTE = 
ONEDEMAND. 


23__INVALID_ MONITOR FLAG. 


The flag specification tn a CMF command is invalid. 


D4__J]NVALID_ STATION LIST. 
A BRC command contains more stations in the destination List than 
exist in the system. 


SUGGESTED ACTION: 
Use fewer stations in the liste. If the List is null» the message its 
sent to ati stations. 


35_FILE_ NOT OPENS 
The MCS received a file close from a program whose remote fil2 is 
not open. 


26__INVALID_INPUT _=-_ MISSING SIGNAL CHAR} 
The MCS received a message from the console keyboard and no signal 
character was present at the beginning of the message. 


SUGGESTED ACTION: 
Re-enter the command with the signal Cas declared in TCL) in position il. 


S/_ _TRANCODE*S PGM DZON*T OPEN THIS STATION. 
The remote file which was opened by the program which handles this 
trancode did not contain this station. 


SUGGESTED ACTION: 
Change the -AMILY statement for this file tn NOL. 
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29__NO_ TRANCQODE AND _STA_NOT_ ATTACHED. 

The message entered did not have a trancode Cor a messag2~-ID if format= 
ting is betng used)» and the station is not attached to a Utility or 
Assignment Program. 


60__USER_ID_NOT_ALLOWED_ AT_ THIS STATION. 
This user is not aditlowed to sign-on at this station. 


61__SECURITY FAILURE =_ INVALID USER“ID- 


The user~ID in a SGN command ts not recognized by the system. 


62__SECURITY FAILURE = USERWID_ DISABLED. 


The user~ID in a SGN command is disadled. 


SUGGESTED ACTION: 
The user cannot sign on until the user-ID is enabled by the EUS command. 


63_ SIGN-ON _NOT REQUIRED. 
A SGN command was received from a station which either does not 
require signing on or is already signed on. 


SUGGESTED ACTION: 
Proceed with normai transactions as if signed one 


64_ _ SECURITY FAILURE = _ SIGN-ON REQUIRED. 

The MCS received a nessage Cother than a SGN command) from a 
Station which requires signing on but ts currently signed off. The 
message just entered is ignored. 


SUGGESTED ACTION: 

Sign on with a SGN command. 

65__ SECURITY FAILURE -_ RESTRICTED PROGRAM. 

A message was entered by auser who ts not allowed to use the 
destination programe. The input message is ignored. 


66. _ SECURITY FAILURE -_ RESTRICTED TRANS} 
A message was entered by aiuser who is not allowed to use the 
transaction code in that messagee The message is ignorei. 


6f__SECURITY FAILURE -_ RESTRICTED NCC. 

A Network Control Coamand was entered from a station that 1s not 
allowed to execute that command. Most commands are aitowed only froa 
the CONTROL STATION. 


68__ SIGNON_ COMPLETE _AT_TIME ON DATES 
A SGN command was successfully processed. 


SUGGESTED ACTION: 
The user is now signed ons and interaction with the system may begin. 
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69__SIGN-OFF COMPLETE _AT_TIME_ON_ DATE. 
A BYE command was successfully processed. 


SUGGESTED ACTION: 
Interaction with the system from this station is prohibited until some 
user successfully signs on againe 


f0__ CHANGE DENTED. 
The Network Controtler responded to a network-change request with a 
change-denied message. 


SUGGESTED ACTION: 
The Network Controtler should be checked to deternitne the reason for 
denial. 


fi__INVALID_ CHANGE TYPE. 
The Network Controller found the type code in a network: hangs 
request to be tavalid. 


SUGGESTED ACTION: 
The maintenance module of the MCS shoutd be checked for possible 
software error. 


72__INVALIOD CHANGE RESULT. 
The Network Controller made an tnvalid response to a change request 
from the MCS. 


SUGGESTED ACTION: 
There may be a problem in the Logic of the Network Controller. 


£3__INVALID CHANGE COMMAND. 
The Network Controller responded to a change request from the MCS» but 
the resovonse is not what the MCS expected. 


SUGGESTED ACTION: 
Investigate the maintenance modute of the MCS for a possibie software 
errore 


74&_ SEND DENIED ON CHANGE. 
The MCS found an error in a change request sent from the MCS to the 
Network Controller. 


SUGGESTED ACTION: 

The change command cannot be processede- Network activity continues» 
but further change requests may be ignored. If more changes are 
critical» the system aust be shut down and restarted. 


(£3 STATION NOT RUNNING. 

An attempt was made to HAP a Utility Program from a station. Ejaither 
the station is not attached to any program or it is not attached to the 
specified program. 
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f6__HAP_COMMAND LOCKOUT» TRY AGAIN. 
The HAP command was temporarily unavailable, thereforers retry the 
command. 


f7__QPEN_DENTED =-_PROG_ ALREADY RUNNING. 


An Assignment Program attempted to open aremote file when there 
already was a copy of that progran runninge. OGntly user programs can 
have multiple copies running. 


SUGGESTED ACTION: 
The Assignment Program must be DSed. 


78__CANNOT EX UTIL PGM FROM CARD OR SPOs 


An EX Network Control Command cannot be entered frorm the Controt sta- 
tion or card reader for programs which have been described in TCL as 
Utility Programs. 


SUGGESTED ACTIONS 
Either enter the EX command from a station or make the regenerate run 
of TCL to describe this program as an Assignment Program or User Program. 


f9__OPEN_ODENTED -_ UTIL PGM NOT _ EXPECTED. 

A program described in TCL as a Utility Program attemoted to open a 
remote file» and the MCS was not expecting the open request (Ciee@e» the 
program was not executed from a station). 


SUGGESTED ACTION: 
DS the program and execute it froa the station that is to use ite 


8O__UNEXPECTED ATTACH REPLY RECEIVED. 
The MCS received an unexpected ATTACH REPLY from the Network Controller. 
The message 1s ignored. 


SUGGESTED ACTION: 

Check MCS and Network Controller logic. 

81__ATTACH REPLY MISMATCH. 

The MCS received an ATTACH REPLY which attached the wrong station or 
the wrong file or both. 


SUGGESTED ACITON: 
Check MCS and Network Controttler logic. 


The last attach request sent by the MCS was dented by the Network 
Controller. The station will not be attached. The possible values 

of denial reason are described in the 8 17090 Systems Network Defination 
Language Reference Manual» form 1073715. 


SUGGESTED ACTION: 
Check MCS and Network Controller Logic. 
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83__UNEXPECTED DETACH REPLY RECELVED. 
The MCS received an unexpected DETACH REPLY from the Netaork Controiler. 


The message 1s tgnored. 


SUGGESTED ACTION: 
Check MCS and Network Controtler logic. 


84__DETACH REPLY MISMATCH. 
The MCS received a DETACH REPLY which detached the wrong station or the 


wrong file or both. 


SUGGESTED ACTIONS 
Check MCS and Network Controller logic. 
BS_STATION NOT _ATTACHEDs INPUT IGNORED. 


If no participating programs are declared in TCL and a station is not 
attached to a programs any message sent from that statton results in 
this error. Entering *HAP without a program name when not attached 
also creates this error conditton. 


86__FMT_ERR» DEST PIR OUT OF BOUNDS. 
The formatted message is targer than MAXTEXTSIZE. 


SUGGESTED ACTION: 
Check description of format in TCL. 


The raw Cunformatted message) is larger than MAXTEXTSIZE. 


SUGGESTED ACTIONS 
Check description of format in TCL. 


88__FEMT_ ERR» NON-DIGZTT IN_INTEGER FIELD. 
The formatting code found a non-numeric character or an embedded biank 
in an integer field. 


SUGGESTED ACTION: 
Check the format description in TCL and the Application Program Logic. 


The message from the Application Program was missing a skip delimiter. 


SUGGESTED ACTION: 
Check the format description in TCL and the Application Program Logic. 


2O_FMT_ERRs VARJABLE REPEAT ON INPUT. 
The station message invoked a foraat containing a variable repeat. 


SUGGESTED ACTION: 


Change the format description in TCL to exclude any variabie re- 
peats on input. 


D-il 


APPENDIX D Ccont) 


J1_EMT_ERRe MISSING DELIMITER. 


The message from the Application Program was missing a delimiter. 


SUGGESTED ACTION: 
Check the format description in TCL and the Application Program logic. 


22__FMT_ERR» INVALID TRANSLATE FTELD. 

The formatter attempted to translate a portion of the message from the 
Application Program using a TRANSLATE functions but the text did not 
match any of the internal strings of that function. 


SUGGESTED ACTION: 
Check the format and function description in TCL and the Application 
Program logic. 


23__QPEN_ DENIED = _ WRONG TCL INTERFACE. 


Fither the Application Program opened a remote fite “with headers®™ and 
the TCL <INTERFACE statement> for that program was not daclared to be 
INTERFACE = MCS» or the INTERFACE was declared to be MCS» but the 
program did not open its remote file "with headers”. 


SUGGESTED ACTION: 
Correct the TCL INTERFACE parameter to match the program and regenerate 
MCSTIC. 


94_ INPUT _ IGNORED DURING RECOVERY. 
The MCS received a message which ts bound for a program that is 
undergoing recovery. The input message 1s ignored. 


SUGGESTED ACTION: 
When recovery is completes enter the message againe Messages may be 
entered for programs not being recovered. 


JS_HAP_NOT_ALLOWED =-_PGM OPENED OUTPUT. 

An attempt was made by a station to *HAP a progran deciared to be 
"output onty™. This ts not accepted since the MCS cannot send an EOF 
to an output~only remote file. 


SUGGESTED ACTION: 
The program must be able to finish without aid from the MCS or it 
must be DSed. 


96_ CAN? T_SEND_EOF TQ _QUIPUT ONLY PGM_# <PROGRAM>. 

During MCS shutdown phase» programs are sent an EDF indiztator which 
requires them to terainate. However» output only programs cannot be 
sent this EOF notice. 


SUGGESTED ACTIONS 
The program must be terminated manually. 
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A program which was not defined in TCL attempted to open a renote file. 


SUGGESTED ACTION: 
DS or DP programe. Modify TCL deck to tinctude this program. 


98_ OPEN DENTED -_ PROGRAM DISABLED. 
A program known to the MCS attempted to open a remote file but the 
program was marked disabled. 


SUGGESTED ACTION: 

DS or OP program. Clear the program (C*CLE) from the console printer or 
Control station. If ali programs belonging to the data base are rnarked 
OK» recovery is then initiated. 


99_ OPEN DENIED - PGM OPENED 2_ RMTE_ FILES*) 
A program attempted to open more than one remote fite concurrently. 
The MCS permits a program oniy one remote open at any given time. 


SUGGESTED ACTION: 
DS or DOP program. Otsatiow program from concurrent remote file opens. 


The MCS received a remote file close message from the Network Control=- 
ler» but the Restart Program was still active. (See errors 101 and 102.) 


SUGGESTED ACTION: 
Check the MCS and Restart Program interface Logic. 


10] _ ENTER "OK" TO RESTART _RESTRY_PGM. 

102_ ENTER_"NO" TO KILL THE MCS. 

These two error messages are displayed on the Controi station or console 
printer when a serious problem is encountered with the Restart Progran. 
A message immediately preceding these errors explains the nature of the 
problen. 


SUGGESTED ACTION: 
Either enter “OK" or *NO” from the console printer by means of the 
accept mechanism. 


1903_OPEN_ DENTED“RESTART PGM_ NOT _ EXPECTED. 
A Restart Program opened a remote file» but the MCS was not expecting a 
remote fite to be open at that time. 


SUGGESTED ACTION: 
DS or DP program. Check the MCS and Restart Program itnterface logic. 


104_ END POSSIBLE. DUPLICATE MESSAGES» 

This error message always occurs in conjunction with error 105. A 
station receives this message after alt possible duplicate messages have 
been displayed at the station at the finish of a synchronized recovery. 
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105 BEGIN POSSIBLE DUPLAICATE MESSAGES. 


This error message and error 104 are displayed at the end of a synchro- 
nized recovery if there are any messages for a station that the MCS 
cannot be sure the station has already seen. These messages are dis- 
played between message 105 and message 104. 


06 _ BUSY. 


An attempt was made to enter a transaction at a station odefore the out- 
put from the previous transaction was received. This only occurs if 
TRANSACTIONMODE = TRUE for that statione The entered transaction is 
ignored. 


SUGGESTED ACTION: 
Wait for output from previous transaction ors enter the RBS network 
control command to reset the busy status of the station. 


2O7_N5G_NOT FOR SYNC DATABASE _PGMe 
An attempt was made to send a message to a program that is not part of 
a synchronized data base (Cas declared tn TCL). 


SUGGESTED ACTIONS 
Either restrict messages from this station to synchronized data base 
programs only or set the TCL station statement TRANSACTIONMODE to FALSE. 


108 _ BEGIN RECOVERY OF _{DATABASE/PROGRAM} = _ <number>es 
109_END_RECOVERY OF {DATABASE/PROGRAM} =_<number>. 

These two messages are displayed on the control station or console 
printer at the start and finish of recovery whenever recovery is tnit > 
tated. For data base and synchronized recovery» the word DATABASE 
appears» otherwise the word PROGRAM aopearse Additionail y» any station 
that attempts to send a message to a orogram currently undergoing 
recovery receives message 109 upon completion of recovery. 


110_GEMNCOS_ARCHIVAL RECOVERY. 
Ji1_ENTER ARCHIVAL SPECIFICATIONS. 


These messages are displayed on the console printer whenever the MCS is 
executed in Archival Recovery mode. 


SUGGESTED ACTION: 
Enter the desired specifications as declared tn this manaal under ARCH- 
IVAL RECOVERY. 


Jic_TNVALID_ARCHIVAL_ SPECIFICATIONS. 
The archival specifications entered at the consote printer were incom 
plete or totatly incomprehensible. 


SUGGESTED ACTION: 
Consult the ARCHIVAL RECOVERY section of this manual to deteragine the 
proper syntax. 
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The archival specifications entered at the consote printer contained a 
word Cindicated in the error message) that was unrecognized or unexpected. 


SUGGESTED ACTIONS 
Consult the ARCHIVAL RECOVERY section of this manuat to detersine the 
proper syntax. 


114_" ALL" MUST BE_ONLY_NAME_IN_ PGM LIST. 


The archivat specifications entered at the console printer contained 
program names in addttion to the word “ALL”. 


SUGGESTED ACTION« 
Either enter a list of progras nares or the word "ALL* at this point in 
the archival specifications. 


113_BEGIN_ARCHIVAL_ RECOVERYs 
116_END_ ARCHIVAL RECOVERY. 


These two messages are displayed on the console printer at th2 start 
and finish of archival recoverys respectively. After displaying message 
116» the MCS terminates. 


AIC_NO_INPUT ALLOWED: ARCHIVAL RECOVERY. 

An attempt was made by a station to send a message to a programs white 
the MCS was in ARCHIVAL RECOVERY sode. This and any oth2r such request 
is ignored. 


SUGGESTED ACTION: 
Do not send any messages to programs during ARCHIVAL RECOVERY. 


118 _ PROGRAM _NOT_IN DATABASE _=-_<nuynber> es 


The archival specifications entered at the consotie printer contain a 
program name that does not belong to the previously mentioned data base. 


SUGGESTED ACTION: 
Check the archival specifications against the TCL specifications de- 
scribing which programs belong to the data base. 


120_MCSTIC TIME MISMATCH - <aydit_file-name>. 
The MCSTIC date/time stamp in the MCSTIC fite for the current audit 
file does not match the MCSTIC date/time stamp in the audit fite. 


SUGGESTED ACTION: 
Check the validity of the MCSTIC file and the audit file named <AUDIT 
FILE-NAME>. 


121_AUDIT FILE TIME MISMATCH -_ <audit file-name>- 
The audit file date/time stamp in the MCSTIC file for the current audit 
file does not match the audit file date/time stamp in the audit fiie. 


SUGGESTED ACTION: 


Check the validity of the MCSTIC file and the audit file named <AUDIT 
FILE“NAME>. 
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122_ CURRENT TIME LESS THAN LAST _ AUDIT. 
The value of the current time maintained by the system clock is Less 
than the time of the last audit performed by the MCS. 


SUGGESTED ACTION: 

Check the validity of the system time clock. 

125_MCS_LOST_ REPLY _TO_<NN>_ INPUTS _TO_PGM _-_<number>. 

During synchronized recovery» the MCS detected <NN> input messages 
from a given station to a prograa for which no output messages were 
ever received. 


SUGGESTED ACTION: 
An inquiry into the data base should be made to see if the transactions 
in question are on the data base. 


426 _ UNEXPECTED CLOSE_FROM PGM = <number>e 

A program that is part of a data base using audtt and rezovery was 
terminated abnormaily. The data base is marked as needing recovery. 
Error message 127 always follows this message. 


427_T0 INITIATE RECOVERY» CLEAR PGM =-_<number>. 

Either this program just terminated abnormaily or an attempt was aade 
to initiate recovery (by the MCS or the user). In either cas2» the 
program must be cleared before recovery can begin. 


SUGGESTED ACTION: 

Clear the disabted program using the *CLE command. If recovery does 
not begins then at least one other program in the data base 3s stilt 
disabled and must also be cleared. 


428 FILE MISSING -__<audit file-name>. 
During recoverys the named audit file was sought on disk by the MCS 
but was not found. 


SUGGESTED ACTIONS 
The named audit fiie must be toaded on disk» and an *AOK command aust 
be entered on the console printer. 


i129 _ FILE LOCKED -_ <audit file-name>. 
During recovery» the MCS tried to open the named audit fite but found 
it was locked by another program. 


SUGGESTED ACTIONS 
The program that locked the named audit file must free it for use by 
the MCS» and an *AOK command must be entered on the console printer. 


130_INCORRECT FILE - <audit file-number>. 

During recovery» the MCS opened the named audit file and determined 
that one or both of the date/time stamps in the file did not anatch the 
vaiue stored in the MCSTIC file. 


SUGGESTED ACTION: 
Check the named file to insure that it is the correct file. 
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J31_ WRONG AUDIT_RECORD. REQUESTED -_PGM_<number>. 

During recovery» the MCS found an error in the audit file during an 
attempt to service a program. The program is DSed if it is part of a 
data base, otherwise» the MCS is terainated. 


SUGGESTED ACTION: 
Either bring the MCS back up or clear the DS5Sed program. 
132_ UNEXPECTED TYPE 22_MSG_FROM PGM_-_<number>. 


This program sent the MCS an unsolicited typer22 messagee A program 
can only send this message upon receipt of a type -2!1 message. The 
program 1s DSed. 


SUGGESTED ACTION: 
Investigate the Logic of this program. Clear the program to initiate 
recovery. 


135 NO AUDITED MESSAGES FOR REF NCC. 
An *REF command was entered to recatl the Last audited osatput message 
for a station» but the MCS had no audited messages for this station. 


134 _ OLD AUDIT FILE MISSING FOR REF NCC. 
An *REF command was entereds but the tast audited message for that 
station was in an audit file that is not on disk. 


SUGGESTED ACTION: 
Load the missing audit fite on diske 


435_ MISSING PROGRAM NAME. 
A Network Controt Command was entered that required either a program 
name or numbers but none was found. 


SUGGESTED ACTION: 
Refer to syntax of the Network Control Command that was itn error. 


136 INVALID PROGRAM -_ <token>. 
The program name or number entered (token) was found to oe either 
invalid or unrecognized. 


SUGGESTED ACTIONS 
Refer to the TCL specifications for a list of att valid program names. 


137_ PROGRAM _NOT_ DISABLED _-_<program name_or_number>. 
An attempt was made to clear a program Cusing the *CLE command) that 
was not disabled. 


SUGGESTED ACTION: 


If there is any doubt of the status of the programs recovery can be 
per formed on that data base. 
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138_INVALID_ DATABASE NAME- <database name _or number>. 
The data base name or number entered was found to be etther invatid or 
unrecognized. 


SUGGESTED ACTION: 
Refer to the TCL specifications for a tist of ali valid data base names. 


439 _ PROGRAM DISABLED _ -_<program name _or number>e. 

An attempt was made to execute this program either by the *EX comaand 
or by entering a trancode for this programs but the program was 
disabled. 


SUGGESTED ACTIONS 
Clear the program with the *CLE command ands thus» initiate recovery of 
this data base. 


440 _ EOF ALREADY SENT TO _-_<progras name>. 
An attempt was made to send a *HAP command to a program more than once. 


SUGGESTED ACTION: 
If the program does not go to EOJ within a few minutes» investigate the 
EOF togic of the remote file of the program. 


141_INPUT_IGNOREDS PROGRAM TERMINATING. _ 
An attempt was made to send a message to a program that is tn the 
process of halting (Ca *#HAP command was performed on this prograa). 


SUGGESTED ACTION: 
Re~execute the program. 


442_UNEXPECTED TYPE _23_M5G_FROM_PGM_=-_<program nuaber>. 
A program sent the MCS a message with MCS~-TYPE fietd of the Common-area 
header set to 25 without first receiving a type "24 message. 


SUGGESTED ACTIONS 
Investigate the program‘s MCS interface logic. 


143_TYPE_17_0R_ 18 _M5G_FROM PROGRAM -_<program nurgber>. 

A program that was not declared in TCL to be a Restart Program sent 

a message to the MCS with MCS-TYPE field of the Common-area header set 
to if or 18. 


SUGGESTED ACTIONS 
Investigate the program's MCS interface Logic. Onty Restart Programs 
can send typevw17 or-18 messages. 


144_REF _NCC_ CANNOT COME FROM SPO- 


An attempt was made to enter a *REF command from the cons ote printer. 
This ts not allowed and is ignored. 
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143_RESTART_PGM RETURNED BAD DATABASE =_<database“namere 


The MCS was expecting the Restart Program to return the name of the 
data base to be recovereds but the nane returned did not match the 
MCS*s expectations. 


SUGGESTED ACTION: 
Investigate the Restart Program's MCS interface logic. The <database- 
name> is what was received by the MCS. 


146_RESTART_PGN FOUND _ ERROR -_ DATABASE <dat abase"name>-s 

The Restart Program found an error while accessing the data base. 
See error messages 101 and 102 for further explanation and suggested 
action. 


147_RESTART PGM RETURNEO BAD POT # -_<POT number>. 

The Restart Program returned a bad value for the PDT number. This 
vaiue was originally stored in the restart data set by the prograa that 
created the record. 


SUGGESTED ACTION: 
Investigate the program logic of all programs tn the data bas2 that 
deals witth the type"23 message. 


The Restart Program returned a bad value for the PROG number. “This 
value was originaliy stored in the restart data set by the progran that 
created the record. 


SUGGESTED ACTION: 


Investigate the program logic that deals with the type "23 message in 
all programs in the data base. 
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APPENDIX E 


SUMMARY OF FILES 


The GEMCOS system files are summarized in the following table. 


Program 


MCSSRC/OBJECT 


MCSSIM 


MCSFIX 


MCSGO 


MCSTCL 


MCSRECALL 


Table Ent 


Summary of GEMCOS 
System Files 


Input CI) 


Internal Name Qutput (0) | Device External Name 


MCSTIC I/0 Disk 
MCSFORMATS 1790 Disk 
MCSQUEUE 1/70 Remote 
MCSBCKLG 1/70 Queue 
MCSAUOIT 1/0 Disk MCSAUDIT/AUDITnnna 
MCSOLDAUDIT 1/0 Disk MCSAUDIT/AUDLITnan 
MCSPRINT D Printer 
MCSTANK 1/0 Disk MCSTANK/<random 
numger> 

PRINT.QOUT 0 Printer MCSSIMPRT 
CARDS I Card “CSSIMCRD 
MCSQUEUE D Queue 
SOURCE I Disk 
NEWSOURCE 0 Disk 
CARDS I Card 
LINE D Printer 

[ Disk 4CSGTS 

I Disk MCSFT5 

I Card MCSCRD 

D Disk MCSSRC 

0 Disk MCSFIT 

1/0 Disk 4CSTMP 

D Printer MCSERN 
MCSIN I Card MCSIN 
MCSLST 0 Printer MCSLST 
MCSPRM 0 Disk MCSTMP 
MCSTIC 0 Disk MCSTIC 
MCSFORMATS 1/0 Disk 4CSFORMATS 
MCSTMP 1/70 Disk MCSTMP1 
OLDMCSTIC I Disk MCSTIC 
MCSRPT D Printer MCSRPT 
DIRECTORY 1/0 Disk work MCSDIRECTY 
MCSTIC I Disk MCSTIC 
MCSREM 1/0 Remote 4CSREM 


Eni 
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Table E-1 (Ccont) 


Summary of GEMCDS 
System Files 


Input CI) 
Program Internal Name Output (0) 


MCSAUDIT 
MCSPRT 


Disk 
Printer 


Externat Nase 


MCSAUDIT/AUDI TIT nan 
MCSPRT 
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COBOL74 


GENERAL- 


The 4.10 release of GEMCOS provides interface capabilities between the 
GEMCOS-generated MCS and COBO0L74 programs. Burroughs COBOL74 coaplies 
to the coding standards established by the American Nattonal Standards 
Institute CANSI) of 1974. (For further information about the COBOL7T4S 
Language» refer to the B 1000 System COBOL74 Reference Manual» form 
number 1108883» for the 9.0 release of the B 1800/8 1700 systams.) 


ICL REQUIREMENTS. 

COBOL74 programs that interface with GEMCOS do not affect or require 
changes in the specifications established in the Transaction Control 
Language (TCL). However» the programs must be dectared in the 
PROGRAM section of the TCL and defined as participating programs in 
order to facititate COBOL74 interface. 


NETWORK OCF INITION LANGUAGE CNDL) REQUIREMENTS. 

The NDL/LIBRARY files provided for the 9.0 release of the B 1800/8 1700 
systems includes COBOL/74 declarations and the COBOL74SEL requ2st set. 
Both the declarations and the request set must be copied from the 
NDOL/LIBRARY file and merged into the appropriate area in the user's NDL 
source file. POLL/SELECT devices» interfacing with COBOL74 programs» 
require a DIAGNOSTIC statement in the TERMINAL section of the 

network definition Language. This statement must specify the request 
sets» POLLICTDs» in the RECEIVE portions and COBOLZ4SEL tn the TRANSMIT 
portion of the statement. An exaaple fottows: 


Example: 


TERMINAL TD8305 
ADDRESS = 2. 
TRANSMISSION = O. 
REQUEST = CANDEPOLTD = RECEIVEs CANDESELTD = TRANSMIT. 
DIAGNOSTIC = POLLTICTD = RECEIVE» COBOL7&5EL = TRANSMIT. 
BUFFERSIZE = 2000. 
TYPE = 46. 


The network controlter is recompiled upon entering specifications such 
as those presented in the example above as well as merging declara- 
tions and the COBOL74SEL request sete. (For additional informations 
refer to the B 1800/B 1700 Systems Network Definition Languag2 (CNDL) 
Reference Manuals form number 1073715.) 


COBOL74 PROGRAM REQUIREMENTS. 

Before COBOL74 programs send messages to the GEMCDOS MCS» they must 
execute the ENABLE <cd-name> or the RECEIVE INPUT <cd“name> command. 
Either command generates a network~controltl FILE OPEN message 

CTYPE = 18)» which is sent to the MCS. The MCS accepts no messages 
from a COBOL74& program until it receives the FILE OPEN message. 
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RESTRICTIONS - 

Multiple COBOL74 programs must not open the same remote file. If 
this occurss the results are unpredictable due to the 9.9 systea 
software implementation. This restriction tlimits the use of the 


MAXCOPIES statement. 


APPENDIX G 


TCL SIZE LIMITATIONS 


The TCL compiter has several size Limitations. They restrict the 
maximum number of various entities such as stations or programs which 
can be dectared in TCL.~j These size Limitations foltow: 


The 
The 
The 
The 
The 
The 
The 
The 
The 


The 


The 


The 


The 


The 


<Maxcopies statement> must be tess than oe a et ae, ae Se, SS 


numsbder 


nuaber 


numbder 


number 


number 


number 


number 


number 


number 


of 
o f 
of 
of 
o f 
of 
of 
o f 


of 


programs must be less than .« « « «© «© «© » « @ 
trancodes must be less than « « «© « «& « « @ « 
message IDs must be tess than « « «© « © @ 2 « 
stations must be less than « « « © « «© «© @ « 
devices must be less than .« « « «© 2» © © @ © © 
functions must be Less than .« « 0 « = «© w= « «© 
formats must be less than « « « «© « «© 2 © «© «@ 
users must be Less than .« « « « «© © «© © © « @ 


trancodes t+ the number of stations +# 


the number of programs must be tess than 2. « «© «© « « @ 


number of programs * ( 83 # <sum of 
maxcopies> ) must be less than .« « «© © © #2 © = &© 2 « « 


number of devices * the number of trancodes * 1) 
must be tess than «=. < « s «© « «© < * .« #@ «© «e ww < «© * 


number of stations «* 
{ 48 + the number of trancodes + 
the number of programs ) must be less than . « © «»@ e« 


number of message~IDs * number of devices * 190 
must be less than = B ® d ® » ® @ a @® 2 = @ ® = @® ® @ 


256 
217 
506 
1023 
131 
1023 
1023 
1023 


1023 


1367 


65535 


65535 


65535 


65535 


INDEX 


Access controls 2-3 

ACCESS CONTROL statements» 3°73 
Appilication-program interfaces» 2-1 
Archival recoverys 97135 9-14 
ATTACH MESSAGE staterzents 3-190 
Audits 2-6 

AUDIT ALL OUTPUT statements» 3-23 
AUDIT ASSIGNMENT statements 3°95 
AUDIT FILE PACK [D statements» 3-38 
AUDIY OK CADK) commands 37-141 
AUDIT OUTPUT statements» 3-96 

AUDIT PAGE SIZE statements 3-37 
AUDIT RECORD SIZE statements 3-36 
Audit & Recovery commands» 3°159 thru 3-161 
AUDIT TRANSACTIONS statements 3794 
Auxiliary programs» section 3 


Basic componentss 3°5 thru 3-10 
Basic syrmboiss 3-4 
BROADCAST CBRC) commands 3-143 


Change commandss 3°151 thru 3-158 

CHANGE MONITOR FLAG CCMF) commands 3-151 

CHANGE REQUESTS statements 3-21 

CHANGE STATION ADDRESS CCSA) comaands 37152 
CHANGE STATION DIAGNOSTIC CCSD) commands 3-153 
CHANGE STATION FREQUENCY CCSF) commands 3°15%4 
CHANGE STATION MAXIMUM RETRY CCS) commands 3°155 
CHANGE STATION QUEUE (CSQ) commands» 37155 

CHANGE STATION READY (CSR) commands 3°157 

CHANGE STATION TRANSMISSION CCST) cormsgand»s 3-158 
Character sets, 3-3 

CHECKPOINT INTERVAL statement» 3-39 

CLEAR BUSY FLAG CCBF) comsgand» 3-139 

CLEAR DISABLED PROGRAM CCLE) commands 37-159 

Ciose files» 3-123 

Congson-area headers 2-ie 2722 2-5» 3°104» 37126 thri 371350 
COMMON SIZE statements 3-89 

COMPELE OPTIONS statements 3-29 

Compiling with MCSTCL» 7-1 

Console or card reader inputs 7-1 

CONTINUOUS LOG-“ON statements 3-109 

CONTROL statements» 3°13 thra 3-17 

CONTROL STATIONS statements 3-71 

Controlied shutdowns 2-56 

Conventions for a "RECOVERY = SYNCHRONIZED" specifications 9-9» 9-10 


one 
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DATA BASE NAME staterents» 3°93 

Data base recovery Cnonsyachronized)» 9-7 
DATA DUMP statemanter 3°22 

Debugging Aids» 2°8 

Deck Descriptions 3-11» 3-12 

DEFINITION sections 3°63 thru 3-7% 

DETACH MESSAGE statergents 3-101 

DEVICE sections 37110 thru 37114 

DISABLE USER (DUS) commands 3-137 

Dynamic declarations» 37117 


ENABLE UScR CEUS) commands 3°135 
Error handiers 3-123 

Error handtings 2°75 

EXECUTE PROGRAM commands 37-1356 
EXECUTE statements 3-90» 3°91 
Executing an MCSs Js-i1 


FAMILY statement of NDL» 2-is 2-2 

Files» GEMCOS systems appendix E 

FORMAT AND "UNCTION statement List» 37465 3-47 
Format dectarations 3-51 thru 3-57 

Formattings 2-9 

Formatting errors» 3°58 thru 3-69 

Function declarations 3748 thru 3°59 


GEMCOS editing pkhrasase 6b-1»s 6°2 
Generations i-i 
GLOBAL sections 3-19 thru 3-71 


HALT APPLICATION PROGRAM CHAP) coamands 37140 
HALT SYSTEM CHLI) commands 3°142 
Handle recalis 3-124 


Identifterss 3-4 
INPUT FORMATS statesgents 3-113 
INTERFACE statements %3-~80 


Logical Station Number CLSN)» 2-1 


MAXIMUM COPIES statements 3-968 

MAXIMUM TEXT SIZE statement» 3-490 

MCS controi commandss 3-141e 37142 

NCS interfaces 3-82 thru 3-84 

MCS output messages» appendix d 

MCS programs iris 1-2 

MCSFiX programs i-32 8-3 thru 8-5 

MCSIN» 3-1 

MCSRECALL» 1-3 

MCSSIM programs 8-i»s 8-2 

MCSTCL (MCS comptterdJsr 1°32 3-1 

MCSTIC (CTable Information Control fileds 1°35 
MCSTIC FILE NAME statements 3°13 
Mergeabdbie external source statementse 2-7 
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MESSAGE BROADCAST statenents 3-23 
Message control commandss 3-143» 37-14% 
MESSAGE RECALL statements 3°24 
Message recovery» 276 

Message routings section 4 

MESS CODE section» 3-815 thru 372819 
MESS procedures» 3-120 thru 37125 
Messages» networks appendix D 
Message types 2-1 

Metalinguistic formulas» 3-2 
Monitors 279s 3-131 

MONITOR TRACE statement» 3-26 
MONITOR TRACE ON statements 3°45 


NAME“STACK ENTRIES statements 3731 

NCC OK RESPONSEs 3-34 

NDL» 21» 2-2 

Network administrations 274» 2°5 

Network Controller CNC)I» 2-4 thru 278 

Network Control Commands (NCCS)» 2-64 thru 2°8» 3°132 thrs 3-151 
Network restorations 2-5 

NONPARTICIPATION interfaces», 3-80» 3-81 

Nonsynchronized and synchronized data base recovery» 373 

No recoverys 9-1e 3-2 


DBJECT“CODE FILE NAME statenment» 3-30 
OPEN MESSAGE statements 3°99 
OUTPUT FORMATS statenents» 3-114 


PARTICIPATION interfaces 3-82 thru 3°84 
POP QUEUE (PQ) commands» 3-144 

Procedure define Lists» 37118» 3-119 
Program aborts 9-56 

PROGRAM BGJ EOS statenents 3-25 

Program control commands» 3°133 thru 3-140 
PROGRAM sections 3-75 thru 3-101 

PROGRAM TITLE statement» 3-87 


QUEUE BUFFERS statements 3-42 

QUEUE DEPTH statements 3-41 

QUEUE NAME statements 3°43 

Queue restoration recoveryr Fr2s 9-3 


RECALL PROGRAM statements 3-70 
RECOVER DATA BASE CREC) commande 37151 
Recoverys section 9 

Recovery after systea fatlures 3-7 
Recovery cycles 9-11l» 9-12 

Recovery procedures 7-2 

Recovery processings 9-7 
Recovery-related conventionsr 9-93 
RECOVERY statements 3-92 

REFRESH CREF) commands 3-159 

Remote file» 2-1» 2-2» 9-4 thru 3-6 
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Remote program executians 2-9 
Repert commandss 3°145 thru 371590 
REPORT DATA DUMP CRDM) commands 37145 
REPORT FILE STATUS CRFS) commands 37145 
REPGRT PROGRAM COUNTERS CRPC) comands 3-148 
REPGRT PROGRAM STATIS CRPS) compards 3-147 
REPORT STATION COUNTERS CRSC) commands 3-143 
REPORT STATION STATUS CRSS) commaads 371590 
RESIDENCE statements 3-38 
Restart programs 9~il 
RESTART PROGRAM statements 3-97 
Routange 2-4&s 278 

(See also Transaction-BSased Routing) 


Securitys 2-29 2-32 2-% 

Security control comaandss 3-134 thru 3-137 
Screen wraparounds 2-8» 2-9 

SCREEN SIZE statement» 37105 

SIGNAL CHARACTER statements 3°35 
SIGN-ON statements» 3-104 

SIMULATION statements 3744 
SOURCE-CUDE FILE NAME statements 3-31 
Static deciarationse 3-115 

STATION LIST statements 3-112 

STATION sections 37-1022 3-103 

STATION section of NDL» 2-1 

STATUS REPORTS statagent» 3-27 
Strings» 3-9 

Summary of fales» appendix E 

Summary of Network Control Coarnands» appendix 8 
Summary of TCL syntax» appendix A 
Supervisory MCS» 2-9 

Synchronized recovery» 9-8 

Syntax conventionss 3-1 

SYSTEM HALT statement» 3-28 

System operations section 7 

System requirements» appendix C 
System structures 1°73 


TRANCODE statements 3-85 

Transactiton“Based Routing CTBR)I» 2-25 273 
TRANSACTION CODE POSITION statemeat» 37106 
Transaction Control Language CTCL)» 1*3» section 3 
Transaction Controt Language compilers i-3 
TRANSACTION MODE statements 3-108 

Transaction processinags 3-6 

Types of recoverys 9-2 thru 9-14 
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User Prograsming Language CUPL)» 1-2 
User prograasse 3-78» 3-79 
Utility programs» 3-77 


¥ALID ACCESS KEYS statements 3-107 
VALUE“STACK BITS statements 3°33 
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